In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.
I'll take UEFI over BIOS any time if only because it finally solved dual booting.
Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?
This stuff seems inches away from a supply chain attack.
It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.
The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer.
A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
And it's absolutely awful as an end user if you have anything even slightly unusual.
Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.
"New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.
Modern computers are distributed systems of components. Each component has its own cpu and OS running in firmware. And they talk over the system bus.
This issue only affects the people who don't want to bother being the root of trust.
With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.
Idle thought - wonder if there are perfect hash-like constructions they could use for revoked certificate lists.
Another potential use is to facilitate managed deprecation of obsolete crypto functions / protocols / hash suites / etc.
That fits pretty well with a 10 year rotation period, and is probably more valuable in the long term than minimising DBX size.