I think your conflating UEFI, with the entire firmware stack. Anyway, there is a bit of LOL here. UEFI DXE/EFI drivers don't have a security model, once they ar

I think your conflating UEFI, with the entire firmware stack. Anyway, there is a bit of LOL here. UEFI DXE/EFI drivers don't have a security model, once they are trusted they have free reign (similar to how a linux module can mostly to anything it wants). But... they don't tend to run under the OS, outside of the very thin UEFI runtime services. Most of UEFI is tossed/overwritten when exit boot services are called. Plus, they are effectively running in the context of the OS kernel which provides the security guarantees. AKA there is nothing gained by finding a bug in the RTC or if someone manage to break the signing chain and provide a bogus firmware update because the exploit happens outside of UEFI itself and doesn't provide more functionality then they already have. Now, that said, you have various ME/BMC processors scattered about, and those are the ones that have frequently been exploited to great advantage. The real chuckle here is that most of the BMC's are running uboot (or similar) firmware/OS stacks which don't tend to be upgraded for the very reasons I pointed out earlier. So yes, your BMC gets owned over the network, and it manages to own the OS running on the main processors because it can inject things into the address space during any part of the boot/runtime. But that isn't a UEFI failing, its a failing of the BMC vendors who don't have a clean way to audit/control the code being built into the images. If you look at OpenBMC its a yocto based system. Which means like android the vendors are on the hook for assuring their system works, and having ongoing development control of the upstream tree's. That all works about as well for BMC's as it does for android.