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

hellerda hellerda at linux.vnet.ibm.com
Mon May 14 07:14:28 AEST 2018 

On 5/11/2018 12:40 PM, hellerda wrote:
> 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
> 
I just added the option --validate-ignore-remainder to print-container. 
With this you should be able to validate padded files, including the 
zImage.epapr in the openpower_pnor_scratch directory.  You can try it at 
https://github.com/open-power/sb-signing-utils/pull/25.
> 
>> 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
>>>
>>
> 
> _______________________________________________
> Skiboot mailing list
> Skiboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot

More information about the Skiboot mailing list