Long time watcher of Level1 channels on Youtube, and first time poster here. Thank you for all the great Linux content over the years - I’m now almost brave enough to try my hand at a VFIO GPU passthrough setup :).
So I’ve been dual booting Ubuntu and Windows for many years, and recently fell down the secure boot rabbit hole. It’s not something I ever thought much about. I just enabled it, and went on about my business.
I recently put together a new build using an Asus B660-A Strix Wifi D4 motherboard. I migrated my existing dedicated Ubuntu NVME drive to this machine. When I booted into Ubuntu and checked the secure boot keys (using "moktuil --“pk”, “mokutil --kek”, and “mokutil --db”), much to my surprise there is a Canonical KEK and DB certificate present. Also, there are 5 hashes present in the DB - I have no idea what those are for.
I checked this in UEFI BIOS directly and get the same listings. When I clear the secure boot keys in the UEFI BIOS and then load defaults, the same entries return. When I clear CMOS and re-flash the BIOS, the same entries return. So these appear to be default entries.
The UEFI BIOS lets me delete individual entries in what it calls “custom mode”. I’ve tried deleting all hashes and the Canonical certificates (leaving just the 2 standard Microsoft certs and 1 Asus cert in the DB, and 1 MS and 1 Asus cert in KEK), and can still boot into Windows and Ubuntu with seemingly no problems. When I change to “standard mode”, all the default keys return (so my deletions are all for naught).
So this inspires a number of questions:
-
Do Asus motherboards come with a Canonical certificate by default?
-
Is it normal for Asus motherboards to have some hashes in the secure boot key DB? If so, to what would they possibly pertain? I’m wondering if it would be for EFI firmware on devices (such as GPU, individual drives, etc.).
-
Is it possible that when I migrated my Ubuntu NVME drive, the Canonical certificates and mystery hashes were somehow automatically added to the secure boot keys? For context, my 8-year-old Asus motherboard that I’m migrating from had a Canonical KEK and DB entry, along with some hashes (unfortunately I didn’t save these for comparison). I don’t see how this could happen - my understanding is that the shim bootloader embeds the Canonical certificate, so it doesn’t need to be added to the secure boot DB. I thought at first the DB hashes might be MOK entries - as I used the MOK facility in my prior build - but my understanding is the MOK is saved elsewhere in NVRAM, not in the secure boot key register.
-
Is it possible that the so-called default keys aren’t in fact default - a problem with the motherboard firmware? Have they somehow been overwritten, making a factory reset of the secure boot keys impossible?
Everything is working great, but I don’t like mystery/necessary keys and hashes among the secure boot keys, especially when I’m not 100% clear on how they got there.
I am really curious to know if others - especially those with Asus boards - have similar secure boot entries.