Skip to content

[Bug]: UEFI PK variable handling. #650

@TBOpen

Description

@TBOpen

Version

7.2.6

Host OS Type

Windows

Host OS name + version

Win11 25H2 26200.8426

Host Architecture

x86

Guest OS Type

all

Guest Architecture

x86

Guest OS name + version

N/A

Component

Unspecified

What happened?

There is a catch-22 with your implementation of PK variable. It can be cleared to put system in setup mode. However if someone tries to reapply the key (saved before delete) via an application it will be rejected, leaving the system in setup mode. All other variables can be updated properly (db, dbx, kek). This leaves the system state in limbo with no way to reinstall the original PK (the default) since an application can't do it and there is no option in the F2 Setup to apply factory default to a single key (like PK). Real systems that incorrectly don't allow updating the PK at least allow changing the system to deployed mode and automatically install just the PK needed. To me this is a bug in the implementation - Also in the UI it talks about *.der, *crt, but then says only takes the DER form. I threw a generic Microsoft OEM DER at it and it took it so now back with secure boot enforced, but the implementation is wrong.

How can we reproduce this?

read above and the implementers should understand it ...

Did you upload all of your necessary log files, screenshots, etc.?

  • Yes, I've uploaded all pertinent files to this issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions