[Skiboot] [PATCH v2 0/7] set the kernel command line from nvram

[Balbir Singh]

On 24/08/16 17:33, Oliver O'Halloran wrote:
> On Fri, Aug 19, 2016 at 2:37 PM, Samuel Mendoza-Jonas
> <sam at mendozajonas.com> wrote:
>> On Fri, 2016-08-19 at 11:50 +1000, Balbir Singh wrote:
>>> On Wed, Aug 17, 2016 at 03:32:47PM +1000, Oliver O'Halloran wrote:
>>>>
>>>> This series allows the kernel command line of the payload kernel to be
>>>> set from nvram. To do this it adds (partial) support for the configuration
>>>> string format used by the nvram utility provided by powerpc-utils.
>>>>
>>>> Example usage:
>>>>
>>>> nvram -p ibm,skiboot --update-config="bootargs=console=tty0 console=hvc0"
>>>>
>>>
>>> Whats the use case? How does this play with secure boot?
>>
>> Currently we need to rebuild Skiroot to change the Skiroot kernel's
>> command line, which is annoying if we want to change the verbosity of the
>> boot console. At least that's the main use case off the top of my head.
> 
> The verbosity of the skiroot kernel slows down boot considerably.
> Ideally it wouldn't make any difference, but the default state of an
> IPMI implementation is "Terrible" so the volume of text forces the
> user to wait until the IPMI daemon can push it all out. Sometimes that
> extra info is useful though so we would like to have a way to turn it
> back on when required.
>

Makes sense
 
>>
>> Secure boot... Not sure.
> 
> This could go a lot of ways and it depends on how we use the contents
> of the nvram partition. Ignoring the kernel command line for a moment,
> if we decide to use nvram config strings for anything that can break
> secure boot, then the only real option is to measure the contents of
> the ibm,skiboot partition. However, this would prevent us from using
> the nvram for runtime configuration which defeats the point of this
> series entirely.
> 
> I was thinking that we could modify the skiroot kernel to only accept
> a whitelist of kernel commend line parameters. By locking down the
> actual kernel measuring the nvram contents would be unnecessary and
> this feature could co-exist with secure boot.

I agree, in fact we could probably just have detection of secure boot
and completely ignore the setting as a the first simple step when
we get there.

As you say we can later decide to whitelist what parameters are acceptable.
But more than measuring the contents of the NVRAM, ideally any changes
should not affect measurements throughout the boot process. So I think
the final solution might be interesting

> 
> Oliver
>