having done a lot (a lot lot) of reading and testing on this subject now I believe that there is still an outstanding issue with the
qm enroll-efi-keys command
I, like others, ran this command against a windows 11 machine, and it does indeed update both the ovmf firmware code (the uefi bios) as well as inserts the relevant keys into the "db" of the uefi vars.. i am however still facing issues with this machine is exhibiting the 1801 event log stating that not all the keys are present..
this i believe is because qm enroll-efi-keys has not updated this VM's efivars to place the "Microsoft corporation kek 2k ca 2023" public key in its KEK
now, with some.. registry tomfoolery.. it is possible to trick the windows updater task to see the new certificate in the db and therefore go ahead with deploying/updating the windows efi boot stub with one that's signed by the "new" 2023 CA.. and yes, it works.... but... still getting 1801 errors..
if i spin up a new VM, head into the bios, head to
device setup > secure boot > custom mode and check the KEK list, the 2023 key *is present* and this further proves my theory that the KEK key
should be present in the efivars
i'm happy to be schooled on this, but reading up on the chain of trust for uefi, my understanding is that while a uefi device is in "user mode" (that is to say, booting securely and tamper locked) if an OS or user intends to update the KEK then that update must be signed by the PK (platform key, usually owned by the vendor e.g. dell or lenovo, etc) - in the case of proxmox, the PK embedded into the OVMF package is from debian, who have created their own PK certificate..
if microsoft's 2023 KEK key has not been signed in by the debian PK present in the VM's existing efivars then microsoft's update process can not and will not be permitted to update the KEK - ergo machines that have been updated through this process at the proxmox cli are at risk of this issue
why is it bad not having the operable KEK onboarded? in the short term, it's not, your VM boots. the KEK is used to authenticate changes to the db (list of permitted secure boot binary signatures) and dbx (list of denied/revoked/compromised secure boot binary signatures) - therefore, it is my assumption that if you have the correct key in your db, and then fudged your existing VM through microsoft's registry merry-go-round to the point where you have updated the boot loader, the next time microsoft pushes out a db or dbx update through a windows update, this VM will not be able to apply that db/dbx update because the KEK they have been signed with is not trusted, and that could potentially lead to boot failures if microsoft's update process doesn't check the health of the efivars beforehand
there's a lot of quasi-complete information available on the internet that refers just to checking the presence of the new certificate in the efi's db - this overlooks the KEK and could lead to troubles later if microsoft doesn't code defensively around db/dbx updates and/or updates to the boot loader. if you check a
certain other popular hypervisor vendor's write-up on this issue, theirs is somewhat similar to my findings in that the admin is encouraged to unseal the efivars, replace the PK with one provided by microsoft (see PKfail github examples too), and in doing so does of course underwrite both their long-standing 2011 KEK as well as the 2023 KEK, allowing the update processes to continue unhindered
one way to solve this problem i believe will be to copy the 2023 KEK file from microsoft into the uefi boot partition of the VM, use the bios then to enter custom mode, and manually upload the KEK to the machine -
*but importantly* if you do this on a machine that has bitlocker/luks disk encryption tied to the tpm/efivars you should unseal it first as doing so will cause a lockout - i need to try this out
in the meantime though, i hope the proxmox team will consider the above scenario
sorry for the ted talk
