3 ms·

Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded server

Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded servers, and exist in a very strict environment with lots of engineering oversight. Its almost the exact definition of a mono-culture. And google is the mother of android, the very definition of huge mess. You need look no further than the handsets being abandoned after a year because its basically impossible to actually maintain without having a staff of dozens of engineers just to keep a platform working. UEFI, is a specification designed to allow a machine to boot and be managed by a multitude of OS's. That means, yes it may be a bit over complicated in places but those over-complications tend to serve a purpose (or did). I don't think anyone imagines that UEFI is perfect, its not, but tossing out uboot or whatever as an alternative is extremely myopic, as uboot doesn't really even provide enough firmware services for linux in its current state much less windows, or some future OS not yet thought off. That is the point with UEFI, to attempt to fill the gaps in what is possible with a given platform without creating a wild west of incompatible formats and hacky solutions for every platform (which is the current state of uboot/DT despite nearly a decade of work).

nickik 8y ago
> Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded servers, and exist in a very strict environment with lots of engineering oversight. They have so many servers and different configuration needs that they need to boot their servers reliably, security, with integrity and they need to boot a wide variety of different systems. > UEFI, is You didn't seem to watch any of the sources that I provided. I'm not making an argument for uboot. The systems that I recommend as better the UEFI can do everything UEFI can do and actually do much more and are much more flexible, not to mention far more secure. > That is the point with UEFI, to attempt to fill the gaps in what is possible with a given platform without creating a wild west of incompatible formats and hacky solutions for every platform (which is the current state of uboot/DT despite nearly a decade of work). You don't seem to know how actually UEFI works on servers. Each vender uses tons of old unsecure bloated firmware full of different drivers that are very badly maintained and don't get security updates. UEFI is at the point where for a commercial server there are more lines of code then the linux OS you are booting into. Its a total security nightmare and a horrible situation in terms of open source as most of these things are closed source. The UEFI core might be open source but even that is not actually used and tracked upstream, vendors all use their own forks. UEFI is complete separated layer that is its own OS, reinventing the wheel putting a totally insecure ring under your OS.
- StillBored 8y ago
  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.

nickik 8y ago

> Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded servers, and exist in a very strict environment with lots of engineering oversight. They have so many servers and different configuration needs that they need to boot their servers reliably, security, with integrity and they need to boot a wide variety of different systems. > UEFI, is You didn't seem to watch any of the sources that I provided. I'm not making an argument for uboot. The systems that I recommend as better the UEFI can do everything UEFI can do and actually do much more and are much more flexible, not to mention far more secure. > That is the point with UEFI, to attempt to fill the gaps in what is possible with a given platform without creating a wild west of incompatible formats and hacky solutions for every platform (which is the current state of uboot/DT despite nearly a decade of work). You don't seem to know how actually UEFI works on servers. Each vender uses tons of old unsecure bloated firmware full of different drivers that are very badly maintained and don't get security updates. UEFI is at the point where for a commercial server there are more lines of code then the linux OS you are booting into. Its a total security nightmare and a horrible situation in terms of open source as most of these things are closed source. The UEFI core might be open source but even that is not actually used and tracked upstream, vendors all use their own forks. UEFI is complete separated layer that is its own OS, reinventing the wheel putting a totally insecure ring under your OS.

StillBored 8y ago
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.