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

Sat May 12 02:20:07 AEST 2018

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.

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
>