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

hellerda hellerda at linux.vnet.ibm.com
Sat May 12 02:40:02 AEST 2018 

On 5/11/2018 12:20 PM, Claudio Carvalho wrote:
> 
> 
> On 11/05/2018 12:46, hellerda wrote:
>>
>> On 5/11/2018 10:29 AM, ppaidipe wrote:
>>> 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.
>>>
>> The zImage.epapr in the output/images directory is just the payload, 
>> not the full container.  There is a file by the same name in the 
>> openpower_pnor_scratch/ directory that is a full container.  You can 
>> check the files using the 'file' command, or examine them with 
>> print-container.
>>
>> Here is where I'm a little unsure: If you run print-container with the 
>> --validate option you will see that it fails validation. There is 
>> another file in openpower_pnor_scratch, the 
>> "rand-xxxxxxxxxx.BOOTKERNEL.temp.hdr.bin" file, that *does* validate. 
>> The difference is, the "hdr.bin" file has no padding applied, and the 
>> zImage.epapr has the padding.
>>
>> I'm not sure which is the correct file to flash.  Probably it is the 
>> zImage.epapr with padding.  Perhaps it does not matter.  It would 
>> matter only if the secure boot code reads beyond the payload size, 
>> when loading the file.  The padding ensures the remainder of the PNOR 
>> partition, after the end of payload, is all nulls.  (At least, I 
>> *think* that's right).
> 
> Does the payload size stored in the container consider the padding? The 
> secure rom code will use that to validate the container.
> 
 >
The payload size in the header does not include the padding.  (which is 
why the padded file fails validation with print-container, while the 
unpadded file passes.  I should add an option to print-container to make 
it consider only payload_size bytes when doing the payload hash 
calculation, so it could be used to check the padded as well as unpadded 
files).  -Dave


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