Over 20 years ago, we had MILO, the "mini-loader" for DEC Alpha machines that was a Linux kernel used as a bootloader to find the real Linux kernel we'd then bo

Over 20 years ago, we had MILO, the "mini-loader" for DEC Alpha machines that was a Linux kernel used as a bootloader to find the real Linux kernel we'd then boot. In that case, it would initialize built-in device drivers to be able to use the network or the block devices, load another kernel file into RAM, and then kexec the new kernel and disappear until the next system reset. It is an interesting wrinkle to ponder leaving such an embedded kernel running in place of UEFI or other SMM hypervisors. Should there be a new syscall layer between the two kernels, or are current SMM traps, ACPI, and UEFI constructs really the right way to do it, even if the same open source community is in charge of both layers? However, a general practice has been that the firmware loaders would be replaced less often and stick with "known good" versions, while the booted kernel could be updated more often. But in this new and threatening world, the firmware kernel can be "known bad", so you need a way to push out updates frequently. You also need a fairly good fail-safe technique to recover when the new update isn't so good after all. And you need to avoid solving this problem with yet another firmware layer which lets you choose between your firmware copies, but itself can be compromised and cannot be easily patched...