Two weeks ago, security researchers managed to disable the Intel Management Engine, and last week, Google held a talk at the Open Source Summit (née LinuxCon) in which they unveiled their plans to completely (well, almost completely) replace every bit of code between the operating system you know about (Windows, Linux, BSD, whatever) and the bare metal x86 processor (Intel-only, for now).

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a "Ring -2 hypervisor"). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs.

Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

I think the larger problem is, how do you verify that the firmware code is actually compiled from that particular source? If you cannot load your own firmware (I know, a pipe dream) how is this different than the current situation? Not just that, if a vulnerability in the current code is found, can you actually update it yourself?

I used to have a Samsung Galaxy Nexus, and know all too well what happens when support is arbitrarily dropped. I would probably still have that phone were I able to load the latest version of Android. But since TI dropped support for the OMAP SoC, I could not upgrade beyond 3.4.

I think the larger problem is, how do you verify that the firmware code is actually compiled from that particular source? If you cannot load your own firmware (I know, a pipe dream) how is this different than the current situation? Not just that, if a vulnerability in the current code is found, can you actually update it yourself?

The other problem is that if you want to do something else (e.g. boot Haiku from USB, boot MS-DOS from CD-ROM, boot FreeBSD from hard drive, etc) you're screwed because they stripped out all of the "non essential" functionality, and if you want to change your hardware (e.g. upgrade the video card) you're also screwed because that'd require a little extensibility.

Mostly it sounds like they're using "open source" as yet another form of vendor lock-in; to make sure the computer will only ever be able to run one specific OS and nothing else (e.g. maybe a special Linux distro created by Google, for Google's benefit and not yours).

Don't know for MacOS and Windows but those can be virtualized via kvm or xen :-)

Awesome - destroy the capabilities the firmware needed to work properly in an attempt to reduce the attack surface; and then increase the attack surface by multiple orders of magnitude more than it ever was to work around the fact that you've destroyed all the capabilities the firmware needs to work properly!

Linux (and its "kexec()") have never officially used or supported Multiboot. Note: if I remember correctly, once upon a time there was a patch written by GRUB developers to add Multiboot support to Linux that was rejected by Linux developers and then died.

Sounds great until Linux updates/improves/changes "kexec()" (or more correctly, the Linux Boot Protocol) and both new versions of Linux and that one "FreeBSD derivative" no longer boot (preventing you from running the firmware update tool/s needed to fix/update the firmware).

Note: The original "kexec()" on Linux was exploitable (allowed unsigned kernels to be booted, so a hacker could use a signed Linux kernel followed by "kexec()" to bypass UEFI Secure Boot); and this was eventually fixed. The patch you linked to has the same exploit without the fix.

Why wouldn't you just put that into one of the existing (shipping) solutions, like Coreboot?

Why wouldn't one put effort into improving an existing OS instead of worrying about that minor hobby one? Cos they can?
Also there seems to be a hardware purist streak amongst some of the existing projects and they might not be accepting of code handling the PSP/IME for political reasons.

I'm partial to the Open Firmware (of which openbios, which you mention, seems to be an implementation) - used in many ~alternative systems (like Pegasos for MorphOS) or in the One Laptop Per Child XO-1 ...not chosen over UEFI seemingly because it just wasn't done by Intel.