Agree with the author that UEFI is bad for security. You have this huge binary UEFI blob in a pre os boot environment that does not run open source. After the motherboard,laptop manufacturer looses interest and they loose interest as soon as the product does not sell more new products UEFI remains unpatched and insecure.
The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source.
Management processors like Intel ME built into the CPU, firmware another x86 insecurity.
UEFI is poorly understood by approximately everybody who doesn't work directly with it and it's frustrating to see so much misinformation out there.
UEFI does not mean that there is a huge binary blob that does not run open source. UEFI is a spec. It defines many steps that must be taken to boot in a compliant way. Large portions of the code that runs in UEFI compliant systems in the wild today are in fact based on an open source 'core' available on github. It is entirely possible to perform a UEFI boot on an entirely open firmware stack, though this tends not to be done. Large silicon vendors like to keep their silicon initialization code proprietary and secret, and they often 'require' tweaks to the open source version of the UEFI 'core' to meet their needs (read: it's seen as easier/cheaper/more-business-friendly to fork the open source core and sprinkle two or three changes throughout and keep the result closed), but there's no reason it needs to be that way.
The author is wrong - there is no 'UEFI kernel' running at any ring after boot. UEFI leaves some code and data in ordinary, OS-accessible memory which can be jumped to and run by the OS if desired to perform some UEFI-related task like setting a boot variable. This code is not protected or hidden or in a special ring and does not require any special steps to invoke. It just sits there waiting to be called and can be modified or deleted if the OS chooses to do so.
SMM is actually a special ring with its own privileges, but there is nothing baked into UEFI which requires using it or leaving code running there. UEFI is extensible and so some platform performing a UEFI boot can leverage a hardware feature like SMM to maintain some control over a platform, but that requires the firmware developers to go out of their way to do that and it can only be done on hardware equipped for it.
But you know what? UEFI is not at fault there. If a platform performed a UEFI boot without touching/configuring SMM at all, then the OS or the bootloader could do the same thing. The hardware capability exists and is accessible by ring 0 until somebody flips a switch to remove that accessibility.
Proprietary, insecure software is a problem. Making firmware fall into that hole is really bad. But UEFI doesn't make that happen. UEFI is just a way of booting that doesn't specifically disallow it, because it's designed to be flexible and extensible and powerful so that a lot of needs can be met. It's completely possible to put together a firmware image which is UEFI compliant and goes out of its way to disable SMM (or any other hardware feature), and boot to an OS that wipes UEFI traces from memory if it feels like it.
Something like Intel's ME existing as an option for businesses who want it is fine. Injecting it into every platform and making it roughly impossible to disable is not. Either way, UEFI is not implicated.
UEFI is not the bad guy. Those who ship UEFI compliant systems which happen to suck are the bad guys. They do it with UEFI, they did it before UEFI, and they would do it without UEFI.
UEFI is still a bad guy, because it is overengineered. And precisely because of that FastBoot mode was invented. Neither Windows, nor Linux (or whatever else) require 90% of UEFI features.
FastBoot just caches a bunch of known things that your system was able to boot with and then doesn't bother re-initializing/re-training/re-discovering various bits and bobs in the hardware.
It's not taking away some 90% of what UEFI does - it's letting UEFI do its thing, writing down what was done for your hardware configuration and the location of your boot image, and then reusing exactly that again on each boot.
That's simple optimization - not a fundamental change to UEFI. Though it is good optimization which certainly could have been baked in from the start.
I never said FastBoot takes 90% away. But it is the example of how simpler things can help firmware be faster and more efficient. I have quite an experience with legacy BIOS modification and RE, UEFI modification and RE, and coreboot development. So I know what I am talking about. One more example of such overengineered thing is the ACPI standard. Especially, since 6.0 version it is tied up to UEFI. EUFI was not designed to be open anyway since it effectively hides the hardware initialization (PI stage) in binary blobs.
UEFI is a beast from the worst times of Microsoft and Intel - this is why it uses PE (Portable Executable) as a format, didn't even bother for optimization, that caused some of the vendors to invent TE format (Terse Executable), which is leaner a bit. And the code, the EDK1/EDK2 code is a perfect example of poorly-written code. Compare it to coreboot or Linux kernel codebase.
> Those who ship UEFI compliant systems which happen to suck are the bad guys.
This. The UEFI implementation on my XPS 13 9343 can't pass kernel command line, unfortunately. Ideally, I would have liked to boot straight into an EFISTUB kernel. Thankfully, there is rEFInd, which I boot as a secondary bootloader.
Well simple and dumb generally is good for all engineered things, as long as they aren't so dumb that they can't do their job.
This principle applies especially well to boot loaders, because the job of a bootloader is to hand control off to some other, more sophisticated piece software.
Unpatched UEFI is more about the reputation of the manufacturer/provider of UEFI. If a major manufacturer releases a motherboard, you can be sure (1) they are patched often and (2) they use similar components across many motherboards so bugs and vulnerabilities are patched across many simultaneously are worked out sooner
Patches existing for the firmware vulnerabilities of major manufacturers is good (I'll take your word for it, having not looked recently, but I know that a few years back this was not the case and known vulnerabilities could be found easily on shipping products).
The pathway from the patch existing to the patch being applied is overgrown with flammable brush. Infrequently traveled. Not healthy. There are efforts to fix this, but they don't have too much momentum at the moment.
1a. Often - that much is true; initially. 1b. For the lifetime of the product? Nope nope nope nope, not in my wildest dreams. What's wrong with a stable, well-built, functioning motherboard? Nothing, just that some years have passed and the mfg no longer has an incentive for support.
The boot loader should be simple and relatively dumb IMHO, then it is secure. If it should be bigger then it should be Open source.
Management processors like Intel ME built into the CPU, firmware another x86 insecurity.