-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support revocation list from uefi.org #22
Comments
Are the revocation lists signed in any way? Would be nice to check that. Also find some way of downloading the correct list for each architecture (potentially just run |
They are, so we can use https://paste.xinu.at/8BFRYyloBkeFQzHfQ/ I also need to write up some better support in |
And now |
Nice! |
Hi, is there a way to do this manually (download, read, sign & enroll) until sbctl supports it? I've been trying to find some doc to do that with limited success. |
If you enroll with Microsoft certificates you can just use However, implementing this feature should be straight forward. Just need to prioritize a bit of time to |
Yeah, I stumbled upon some doc on that and have it installed but apparently it supports 0 device on my computer so not sure how useful it is to me atm. I just tried
Your project is a great help already, thanks a lot! |
I managed to merge the "official" dbxupdate_x64.bin file (https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin ) with the existing hashes in dbx and enroll both together again in UEFI SecureBoot NVRAM!
|
This should be rather trivial: The official revocation list is signed by Microsoft Corporation KEK CA 2011. You just need to add that one to the KEK db if microsoft keys are used. In case where the user does not use microsoft keys, the whole revocation list is useless anyways. Also, updating this list could/should be left to fwupdmgr (though, I find it rather odd that it only offers version 77 when the official list is at 211 by now). |
Nah, for the sake of doing it easy you just strip the Authentication header and resign it with the user-enrolled KEK. I don't think it's strictly useless as it would prevent users from signing old iterations of the Fedora shim.
Did this ever leave the testing branch? My impression was that it was sorta implemented once and never really progressed. It would also break unless the Microsoft KEK is enrolled, and I don't know how that failure mode looks like. |
Why sign fedora shim in the first place when you use custom keys? Just add the fedora key to db. In fact, if you use shim, you'd be using ms keys anyways and therefore should really be adding the ms KEK key.
The failure mode is very simple: If the dbx update is not trusted, the write is simply refused by the firmware and nothing happens. |
It makes sense to sign the |
That sounds weird. Got a link for me? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-kernel-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel says that the Secure Boot db is added to the kernel keyring and so any key in there should be usable for kernel module signing. So all you'd need to do is take the key that is backed into a distros shim (or whichever key is used to sign the modules) and add it to the db, no? |
No :) This is because of an rejected upstream patch that RH/Fedora/Ubuntu/SUSE is backporting against the will/intention of the kernel maintainers. This functionality does not exist in the upstream kernel and was explicitly removed years ago. See #52 (comment)
Understandable! I have not figured out another way to load a key the kernel trusts for module signatures, which makes the entire scenario a bit bizzare. See https://patchwork.kernel.org/project/keyrings/list/?series=608506 and #52 (comment) |
I tried it with the motherboard shipped DBX combined with sbctl and Microsoft keys but haven't been able to get fwupd to give an update for it, but it does do so under other distros like Debian and Fedora with their stock secure boot setup. Is Microsoft Corporation KEK CA 2011 needed for that to work? Not sure if there would be a way to include that in the current setup if it is required. |
For the dbx to be enrolled it needs to be signed by a trusted KEK. The revocation list as distributed by the UEFI forum is signed by the MS KEK, so that one has to be trusted. fwupd.efi also has to be trusted by a db key. On debian and fedora it's signed with the vendor key and relies on shim, on arch you'd have to sign it with sbctl. Or one could resign the dbx update with the sbctl KEK. Afaik, it's the same format for the other db variables. Dunno if stripping the original signature is needed or not. |
I'm quite sure the LVFS update capsules for |
I just checked, and the LVFS update contains the same dbx file as the one provided by the UEFI forum and from what I can tell are enrolled by writing to the efivar in userspace. So, MS KEK would have to be trusted for fwupd to work. |
Ah I see, I did notice a while back Windows would try to push DBX updates like KB5012170 in particular but those would fail with the current MS enrolled keys sbctl has. To workaround that I cleared out the sbctl keys for factory and that update went through and I removed the MS keys again and reenrolled sbctl keys afterwards. I'm wondering in that case as well if using MS KEK might resolve that too. |
it would be cool to load the lists into
dbx
.https://uefi.org/revocationlistfile
The text was updated successfully, but these errors were encountered: