[Skiboot] [PATCH] libstb/secureboot: Disable secureboot in OPAL by nvram

[ppaidipe]

On 2018-05-11 18:24, Claudio Carvalho wrote:
> On 11/05/2018 09:33, ppaidipe wrote:
>> On 2018-05-11 17:47, Claudio Carvalho wrote:
>>> ---
>>> Claudio Carvalho
>>> Linux Security Development - IBM LTC
>>> 
>>>> ----- Original message -----
>>>> From: ppaidipe <ppaidipe at linux.vnet.ibm.com>
>>>> To: Nayna Jain <nayna at linux.vnet.ibm.com>
>>>> Cc: skiboot at lists.ozlabs.org, George Wilson <gcwilson at us.ibm.com>,
>>>> Claudio Carvalho/Brazil/IBM at IBMBR, hellerda at us.ibm.com,
>>>> erichte at us.ibm.com, sarahw at us.ibm.com
>>>> Subject: Re: [Skiboot] [PATCH] libstb/secureboot: Disable secureboot
>>>> in OPAL by nvram
>>>> Date: Fri, May 11, 2018 9:04 AM
>>>> 
>>>> On 2018-05-11 16:52, Nayna Jain wrote:
>>>>> On 05/09/2018 02:40 PM, Pridhiviraj Paidipeddi wrote:
>>>>>> Currently custom debug petitboot kernels failed to boot on
>>>> secureboot
>>>>>> enabled systems as the key verification fails results in
>>>> enforcing the
>>>>>> boot. Due to which debugging any problems in petitboot kernel in
>>>>>> secure
>>>>>> boot enabled systems become hard.
>>>>>> This patch provides a way to disable secureboot in OPAL by using
>>>> below
>>>>>> nvram command.
>>>>> 
>>>>> Petitboot verification should not be disabled if firmware secure
>>>> boot
>>>>> is on. Its only Host OS kernel
>>>>> for which we can have the switch.
>>>>> 
>>>>> This patch can result in a loophole where someone as application
>>>> user
>>>>> can disable
>>>>> verification of petitboot kernel using nvram utility.
>>>> 
>>>> Yeah, agree, but this is really a debug hack, without that there are
>>>> bugs related to keys
>>>> in upstream vs vendor released firmware, due to which verification
>>>> fails
>>>> and boot enforce
>>>> happening on secureboot enabled systems,
>>> 
>>> I'm not sure if I know what bug you are talking about here. Can you
>>> elaborate more on that?
>> 
>> Yes, Lets say p9dsu system is having latest supermicro released 
>> firmware(having imprint keys)
>> and secureboot mode is enabled in the system. If we compile custom 
>> kernel in upstream op-build
>> using development mode in signed mode and flash that on that failed 
>> secureboot system. so when
>> we boot with that kernel, keys verification is failing, i am not sure 
>> why it is failing now, earlier
>> it works when doing testing. The kernel tried from both the places one 
>> is zImage.epapr and another
>> one is extracted BOOTKERNEL partition from full PNOR built in signed 
>> imprint mode. Using both the images
>> verification is failing now.
> 
> Hmm ... as long as the system trusts the imprinting keys (not any
> production key), you should still be able to build and boot custom
> zImage.epapr signed with imprinting keys. Do you remember how you
> built (and signed) the zImage.epapr?
> 

Yeah, on current upstream op-build, add this patch 
https://github.com/open-power/op-build/pull/1988 to enable
secureboot and build signed imprint PNOR, before build we will add some 
custom patches to linux in openpower/linux folder
and then do full op-build. Then try to flash the BOOTKERNEL which is 
extracted from full PNOR image built, then we
will hit it.

Thanks
Pridhiviraj

> Claudio
> 
>> 
>>> 
>>> Thanks,
>>> Claudio
>>> 
>>>> so we need a way to force
>>>> disable it, like the way
>>>> we have for enabling it via nvram. Otherwise debugging petitboot
>>>> kernels
>>>> on such systems
>>>> became really hard.
>>>> 
>>>> Thanks
>>>> Pridhiviraj
>>>> 
>>>>> 
>>>>> Thanks & Regards,
>>>>> - Nayna
>>>>> 
>> 
>> _______________________________________________
>> Skiboot mailing list
>> Skiboot at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/skiboot