> I read your replacement a little different.
>
> - if ((InCustomMode () && UserPhysicalPresent ()) || ((mPlatformMode ==
> SETUP_MODE) && !IsPk)) {
>
> with
>
> + if ( (InCustomMode () && UserPhysicalPresent ())
> + || ( (mPlatformMode == SETUP_MODE)
> +&& !(FeaturePcdGet
Hi Sean,
> From looking over the patch 1/4 email i have a concern.
>
> In AuthService.c on the conditional change you made. Aren't we losing
> a case where we are evaluating a nonPK payload signed by the PK?
> Given the system is in SetupMode that means there is no PK but is this
> the
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4305
Based on whether the DER-encoded ContentInfo structure is present in
authenticated SetVariable payload or not, the SHA-256 OID can be
located at different places.
UEFI specification explicitly states the driver shall support both
cases,
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506
Change the default value of PcdRequireSelfSignedPk to FALSE in
accordance with UEFI spec, which states that PK need not be
self-signed when enrolling in setup mode.
Note that this relaxes the legacy behavior, which required the PK to
be
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506
Per UEFI spec, enrolling a new PK in setup mode should not require a
self-signature. Introduce a feature PCD called PcdRequireSelfSignedPk
to control this requirement. Default to TRUE in order to preserve the
legacy behavior.
Cc: Jiewen
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506
In all DSC files that define SECURE_BOOT_ENABLE, opt-in into requiring
self-signed PK when SECURE_BOOT_ENABLE is TRUE.
Cc: Ard Biesheuvel
Cc: Jiewen Yao
Cc: Jordan Justen
Cc: Gerd Hoffmann
Cc: Rebecca Cran
Cc: Peter Grehan
Cc:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2506
In all DSC files that define SECURE_BOOT_ENABLE, opt-in into requiring
self-signed PK when SECURE_BOOT_ENABLE is TRUE.
Cc: Ard Biesheuvel
Cc: Leif Lindholm
Cc: Sami Mujawar
Cc: Gerd Hoffmann
Signed-off-by: Jan Bobek
---
Hi all,
I'm sending out v1 of my patch series that addresses a UEFI spec
non-compliance when enrolling PK in setup mode. Additional info can be
found in bugzilla [1]; the changes are split into 4 patches as
suggested by Laszlo Ersek in comment #4.
I've based my work on the patch by Matthew
> I linked email with Bugzilla. Either email or Bugzilla is OK for the
> discussion.
Sounds good.
> Personally, I don't understand one thing.
> If EDKII causes such failure, how the archlinux validates the correctness of
> the tool and document in [3] ?
>
> Or are they using a different UEFI
> Hi
> That is good catch!
> My apology to miss it before.
>
> 1) Please file a bugzilla (https://bugzilla.tianocore.org/) to record the
> issue and associate to the patch.
Filed bug 4305 [1]. Sorry for the delay, I didn't get my bugzilla
credentials until late last week.
> 2) Would you please
Anothing ping. Comments/reviews/merge highly appreciated.
Thank you,
-Jan
Jan Bobek writes:
> Ping. Can I get a review and/or some comments on this patch, please?
>
> Thanks,
> -Jan
>
> Jan Bobek writes:
>
>> Based on whether the DER-encoded ContentInfo structure is present in
>> authenticated
Ping. Can I get a review and/or some comments on this patch, please?
Thanks,
-Jan
Jan Bobek writes:
> Based on whether the DER-encoded ContentInfo structure is present in
> authenticated SetVariable payload or not, the SHA-256 OID can be
> located at different places.
>
> UEFI specification
Based on whether the DER-encoded ContentInfo structure is present in
authenticated SetVariable payload or not, the SHA-256 OID can be
located at different places.
UEFI specification explicitly states the driver shall support both
cases, but the old code assumed ContentInfo was not present and
13 matches
Mail list logo
