Hello
I have read https://bugzilla.tianocore.org/show_bug.cgi?id=2506 and https://edk2.groups.io/g/devel/topic/32283314#43150. That seems make sense to me.

Would you please send out the patch set, we can continue the review process?

Thank you
Yao, Jiewen

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sean
Sent: Saturday, January 7, 2023 6:51 AM
To: discuss@edk2.groups.io; jbobek@...
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Xu, Min M <min.m.xu@...>
Subject: Re: [edk2-discuss] Clarification: Enrolling PK from PKDefault

Yes, I agree with your #2. Tianocore is broken and not spec compliant
and if any platform used it as is then PK default workflow would not work.

We opened a bug a few years ago: 2506 – When setting a new PK in setup
mode, PK should not be required to be self-signed (tianocore.org)
<https://bugzilla.tianocore.org/show_bug.cgi?id=2506>

And our Project Mu contains patches/changes to fix this.

Thanks

Sean



On 1/3/2023 3:51 PM, Jan Bobek via groups.io wrote:

Hello all,

I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).

The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:

While no Platform Key is enrolled, the SetupMode variable shall be
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.

In other words, when no Platform Key is enrolled, no authentication
should be required to modify it.

The platform owner enrolls the public half of the Platform Key (PKpub)
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.

When the platform is in setup mode, the new PKpub MAY (but need not)

be

signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.

The authenticated PK variable can always be read but can only be
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.

The authenticated PK variable can be written if the platform is in setup
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.

The platform vendor may provide a default PKpub in the PKDefault
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied

to

the Platform Key variable using the SetVariable() call.

When in setup mode, one can read the contents of "PKDefault" variable,
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.

I have two notes w.r.t. the above:

1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?

2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.

Thanks in advance for any input,
-Jan Bobek

References:

[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.ht
ml#firmware-os-key-exchange-creating-trust-relationships

[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/Aut
hVariableLib/AuthService.c#L606

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sean
Sent: Saturday, January 7, 2023 6:51 AM
To: discuss@edk2.groups.io; jbobek@...
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Xu, Min M <min.m.xu@...>
Subject: Re: [edk2-discuss] Clarification: Enrolling PK from PKDefault

Yes, I agree with your #2.  Tianocore is broken and not spec compliant
and if any platform used it as is then PK default workflow would not work.

We opened a bug a few years ago: 2506 – When setting a new PK in setup
mode, PK should not be required to be self-signed (tianocore.org)
<https://bugzilla.tianocore.org/show_bug.cgi?id=2506>

And our Project Mu contains patches/changes to fix this.

Thanks

Sean



On 1/3/2023 3:51 PM, Jan Bobek via groups.io wrote:

Hello all,

I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).

The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:

While no Platform Key is enrolled, the SetupMode variable shall be
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.

In other words, when no Platform Key is enrolled, no authentication
should be required to modify it.

The platform owner enrolls the public half of the Platform Key (PKpub)
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.

When the platform is in setup mode, the new PKpub MAY (but need not)

be

signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.

The authenticated PK variable can always be read but can only be
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.

The authenticated PK variable can be written if the platform is in setup
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.

The platform vendor may provide a default PKpub in the PKDefault
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied

to

the Platform Key variable using the SetVariable() call.

When in setup mode, one can read the contents of "PKDefault" variable,
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.

I have two notes w.r.t. the above:

1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?

2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.

Thanks in advance for any input,
-Jan Bobek

References:

[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.ht
ml#firmware-os-key-exchange-creating-trust-relationships

[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/Aut
hVariableLib/AuthService.c#L606

Hello all,

I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).

The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:

While no Platform Key is enrolled, the SetupMode variable shall be
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.

In other words, when no Platform Key is enrolled, no authentication
should be required to modify it.

The platform owner enrolls the public half of the Platform Key (PKpub)
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.

When the platform is in setup mode, the new PKpub MAY (but need not) be
signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.

The authenticated PK variable can always be read but can only be
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.

The authenticated PK variable can be written if the platform is in setup
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.

The platform vendor may provide a default PKpub in the PKDefault
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied to
the Platform Key variable using the SetVariable() call.

When in setup mode, one can read the contents of "PKDefault" variable,
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.

I have two notes w.r.t. the above:

1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?

2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.

Thanks in advance for any input,
-Jan Bobek

References:
[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html#firmware-os-key-exchange-creating-trust-relationships
[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/AuthVariableLib/AuthService.c#L606