5 ms·

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 m

• fghtr 7y ago
  >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. I do not see why it would be different for any other software.
  • jraph 7y ago
    It's not, in my opinion. And if the piece of software is simple and dumb, I don't really see why it should not be open source neither.
  • adrianratnapala 7y ago
    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.
  • marcosdumay 7y ago
    Well, you can sandbox anything that is loaded on top of a Free layer, you computer's boot firmware is certainly not on such place.
• parentheses 7y ago
  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
  • kr99x 7y ago
    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.
    • parentheses 7y ago
      I concur that in practice most hardware can easily remain unpatched. Installing upgrades can be scary (at least it was for my first home PC builds).
      • brokenmachine 7y ago
        Installing firmware/BIOS updates is the scariest thing I ever do on a computer.
  • Piskvorrr 7y ago
    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.
• kr99x 7y ago
  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.