libstb/secureboot: Disable secureboot in OPAL by nvram

Message ID 1525857024-14483-1-git-send-email-ppaidipe@linux.vnet.ibm.com
State Rejected
Headers show
Series
  • libstb/secureboot: Disable secureboot in OPAL by nvram
Related show

Commit Message

ppaidipe May 9, 2018, 9:10 a.m.
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.
nvram -p ibm,skiboot --update-config force-secure-mode=false

Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
---
 libstb/secureboot.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Nayna Jain May 11, 2018, 11:22 a.m. | #1
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.

Thanks & Regards,
    - Nayna

> nvram -p ibm,skiboot --update-config force-secure-mode=false
>
> Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
> ---
>   libstb/secureboot.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/libstb/secureboot.c b/libstb/secureboot.c
> index 348acf5..8c8a9d6 100644
> --- a/libstb/secureboot.c
> +++ b/libstb/secureboot.c
> @@ -107,6 +107,9 @@ void secureboot_init(void)
>   	if (nvram_query_eq("force-secure-mode", "always")) {
>   		secure_mode = true;
>   		prlog(PR_NOTICE, "secure mode on (FORCED by nvram)\n");
> +	} else if (nvram_query_eq("force-secure-mode", "false")) {
> +		secure_mode = false;
> +		prlog(PR_NOTICE, "secure mode off (FORCED by nvram)\n");
>   	} else {
>   		secure_mode = dt_has_node_property(node, "secure-enabled", NULL);
>   		prlog(PR_NOTICE, "secure mode %s\n",
ppaidipe May 11, 2018, 12:07 p.m. | #2
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, 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
> 
>> nvram -p ibm,skiboot --update-config force-secure-mode=false
>> 
>> Signed-off-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>> ---
>>   libstb/secureboot.c | 3 +++
>>   1 file changed, 3 insertions(+)
>> 
>> diff --git a/libstb/secureboot.c b/libstb/secureboot.c
>> index 348acf5..8c8a9d6 100644
>> --- a/libstb/secureboot.c
>> +++ b/libstb/secureboot.c
>> @@ -107,6 +107,9 @@ void secureboot_init(void)
>>   	if (nvram_query_eq("force-secure-mode", "always")) {
>>   		secure_mode = true;
>>   		prlog(PR_NOTICE, "secure mode on (FORCED by nvram)\n");
>> +	} else if (nvram_query_eq("force-secure-mode", "false")) {
>> +		secure_mode = false;
>> +		prlog(PR_NOTICE, "secure mode off (FORCED by nvram)\n");
>>   	} else {
>>   		secure_mode = dt_has_node_property(node, "secure-enabled", NULL);
>>   		prlog(PR_NOTICE, "secure mode %s\n",
Claudio Carvalho May 11, 2018, 12:17 p.m. | #3
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div dir="ltr" >&nbsp;</div>
<div dir="ltr" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><div><font size="2" face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" >---</font></div>
<div><font size="2" face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" >Claudio Carvalho</font></div>
<div><font size="2" face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" >Linux Security Development - IBM LTC</font></div></div></div></div></div></div></div></div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >&nbsp;</div>
<blockquote data-history-content-modified="1" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: ppaidipe &lt;ppaidipe@linux.vnet.ibm.com&gt;<br>To: Nayna Jain &lt;nayna@linux.vnet.ibm.com&gt;<br>Cc: skiboot@lists.ozlabs.org, George Wilson &lt;gcwilson@us.ibm.com&gt;, Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com, erichte@us.ibm.com, sarahw@us.ibm.com<br>Subject: Re: [Skiboot] [PATCH] libstb/secureboot: Disable secureboot in OPAL by nvram<br>Date: Fri, May 11, 2018 9:04 AM<br>&nbsp;
<div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >On 2018-05-11 16:52, Nayna Jain wrote:<br>&gt; On 05/09/2018 02:40 PM, Pridhiviraj Paidipeddi wrote:<br>&gt;&gt; Currently custom debug petitboot kernels failed to boot on secureboot<br>&gt;&gt; enabled systems as the key verification fails results in enforcing the<br>&gt;&gt; boot. Due to which debugging any problems in petitboot kernel in<br>&gt;&gt; secure<br>&gt;&gt; boot enabled systems become hard.<br>&gt;&gt; This patch provides a way to disable secureboot in OPAL by using below<br>&gt;&gt; nvram command.<br>&gt;<br>&gt; Petitboot verification should not be disabled if firmware secure boot<br>&gt; is on. Its only Host OS kernel<br>&gt; for which we can have the switch.<br>&gt;<br>&gt; This patch can result in a loophole where someone as application user<br>&gt; can disable<br>&gt; verification of petitboot kernel using nvram utility.<br><br>Yeah, agree, but this is really a debug hack, without that there are<br>bugs related to keys<br>in upstream vs vendor released firmware, due to which verification fails<br>and boot enforce<br>happening on secureboot enabled systems,</font></div>
<div>&nbsp;</div>
<div>&nbsp;</div></blockquote>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >I'm not sure if I know what bug you are talking about here. Can you elaborate more on that?</div>
<div dir="ltr" >&nbsp;</div>
<div dir="ltr" >Thanks,</div>
<div dir="ltr" >Claudio</div>
<div dir="ltr" >&nbsp;</div>
<blockquote class="history-quote-1526040784418" data-history-content-modified="1" data-history-expanded="1" dir="ltr" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" ><div><font size="2" face="Default Monospace,Courier New,Courier,monospace" >so we need a way to force<br>disable it, like the way<br>we have for enabling it via nvram. Otherwise debugging petitboot kernels<br>on such systems<br>became really hard.<br><br>Thanks<br>Pridhiviraj<br><br>&gt;<br>&gt; Thanks &amp; Regards,<br>&gt; &nbsp;&nbsp; - Nayna<br>&gt;<br>&gt;&gt; nvram -p ibm,skiboot --update-config force-secure-mode=false<br>&gt;&gt;<br>&gt;&gt; Signed-off-by: Pridhiviraj Paidipeddi &lt;ppaidipe@linux.vnet.ibm.com&gt;<br>&gt;&gt; ---<br>&gt;&gt; &nbsp; libstb/secureboot.c | 3 +++<br>&gt;&gt; &nbsp; 1 file changed, 3 insertions(+)<br>&gt;&gt;<br>&gt;&gt; diff --git a/libstb/secureboot.c b/libstb/secureboot.c<br>&gt;&gt; index 348acf5..8c8a9d6 100644<br>&gt;&gt; --- a/libstb/secureboot.c<br>&gt;&gt; +++ b/libstb/secureboot.c<br>&gt;&gt; @@ -107,6 +107,9 @@ void secureboot_init(void)<br>&gt;&gt; &nbsp; if (nvram_query_eq("force-secure-mode", "always")) {<br>&gt;&gt; &nbsp; secure_mode = true;<br>&gt;&gt; &nbsp; prlog(PR_NOTICE, "secure mode on (FORCED by nvram)\n");<br>&gt;&gt; + } else if (nvram_query_eq("force-secure-mode", "false")) {<br>&gt;&gt; + secure_mode = false;<br>&gt;&gt; + prlog(PR_NOTICE, "secure mode off (FORCED by nvram)\n");<br>&gt;&gt; &nbsp; } else {<br>&gt;&gt; &nbsp; secure_mode = dt_has_node_property(node, "secure-enabled", NULL);<br>&gt;&gt; &nbsp; prlog(PR_NOTICE, "secure mode %s\n",</font></div></blockquote>
<div dir="ltr" >&nbsp;</div></div><BR>
ppaidipe May 11, 2018, 12:33 p.m. | #4
On 2018-05-11 17:47, Claudio Carvalho wrote:
> ---
> Claudio Carvalho
> Linux Security Development - IBM LTC
> 
>> ----- Original message -----
>> From: ppaidipe <ppaidipe@linux.vnet.ibm.com>
>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>> erichte@us.ibm.com, sarahw@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.

> 
> 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
>>>
Claudio Carvalho May 11, 2018, 12:54 p.m. | #5
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@linux.vnet.ibm.com>
>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>> erichte@us.ibm.com, sarahw@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?

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@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot
ppaidipe May 11, 2018, 1:09 p.m. | #6
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@linux.vnet.ibm.com>
>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>> erichte@us.ibm.com, sarahw@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@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/skiboot
hellerda May 11, 2018, 1:19 p.m. | #7
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@linux.vnet.ibm.com>
>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>> erichte@us.ibm.com, sarahw@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.


> 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@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/skiboot
ppaidipe May 11, 2018, 2:29 p.m. | #8
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@linux.vnet.ibm.com>
>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>> erichte@us.ibm.com, sarahw@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@lists.ozlabs.org
>>>> https://lists.ozlabs.org/listinfo/skiboot
hellerda May 11, 2018, 3:46 p.m. | #9
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@linux.vnet.ibm.com>
>>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>>> erichte@us.ibm.com, sarahw@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).

>>
>>> 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@lists.ozlabs.org
>>>>> https://lists.ozlabs.org/listinfo/skiboot
Claudio Carvalho May 11, 2018, 4:20 p.m. | #10
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@linux.vnet.ibm.com>
>>>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>>>> erichte@us.ibm.com, sarahw@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@lists.ozlabs.org
>>>>>> https://lists.ozlabs.org/listinfo/skiboot
>
hellerda May 11, 2018, 4:40 p.m. | #11
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@linux.vnet.ibm.com>
>>>>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>>>>> erichte@us.ibm.com, sarahw@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@lists.ozlabs.org
>>>>>>> https://lists.ozlabs.org/listinfo/skiboot
>>
>
hellerda May 13, 2018, 9:14 p.m. | #12
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@linux.vnet.ibm.com>
>>>>>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson 
>>>>>>>>>> <gcwilson@us.ibm.com>,
>>>>>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>>>>>> erichte@us.ibm.com, sarahw@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@lists.ozlabs.org
>>>>>>>> https://lists.ozlabs.org/listinfo/skiboot
>>>
>>
> 
> _______________________________________________
> Skiboot mailing list
> Skiboot@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot
Stewart Smith May 28, 2018, 2:08 a.m. | #13
hellerda <hellerda@linux.vnet.ibm.com> writes:
> 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@linux.vnet.ibm.com>
>>>>>>>> To: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>>>>>> Cc: skiboot@lists.ozlabs.org, George Wilson <gcwilson@us.ibm.com>,
>>>>>>>> Claudio Carvalho/Brazil/IBM@IBMBR, hellerda@us.ibm.com,
>>>>>>>> erichte@us.ibm.com, sarahw@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).

It shouldn't make a difference as the signature should just be across
the content of the partition and not the full thing, otherwise we
certainly have a decent sized bug.
Stewart Smith May 28, 2018, 2:09 a.m. | #14
Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> writes:
> 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.
> nvram -p ibm,skiboot --update-config force-secure-mode=false

As mentioned by others, this isn't something I can take for upstream as
it really does bypass the point of secure mode.

Patch

diff --git a/libstb/secureboot.c b/libstb/secureboot.c
index 348acf5..8c8a9d6 100644
--- a/libstb/secureboot.c
+++ b/libstb/secureboot.c
@@ -107,6 +107,9 @@  void secureboot_init(void)
 	if (nvram_query_eq("force-secure-mode", "always")) {
 		secure_mode = true;
 		prlog(PR_NOTICE, "secure mode on (FORCED by nvram)\n");
+	} else if (nvram_query_eq("force-secure-mode", "false")) {
+		secure_mode = false;
+		prlog(PR_NOTICE, "secure mode off (FORCED by nvram)\n");
 	} else {
 		secure_mode = dt_has_node_property(node, "secure-enabled", NULL);
 		prlog(PR_NOTICE, "secure mode %s\n",