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

ppaidipe ppaidipe at linux.vnet.ibm.com
Sat May 12 00:29:33 AEST 2018


On 2018-05-11 18:49, hellerda wrote:
> On 5/11/2018 9:09 AM, ppaidipe wrote:
>> 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.
>> Does this happen if you flash the full PNOR image or only if try to 
>> flash the partition individually?  If just the latter, maybe the 
>> partition reflash does not work exactly as we expect.
> 
> Claudio, correct me if I'm wrong but I think flashing the zImage.epapr
> will not work here because that is not a complete, signed container;
> it is only the payload.
> 

I have tried both payload image(zImage.epapr), BOOTKERNEL 
partition(signed container) extracted
from full PNOR. Both are failed. And regarding full PNOR image, which is 
long ago bug system won't
boot due to SBE's are messed up.

> 
>> 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



More information about the Skiboot mailing list