Replacing exploit-ridden firmware with a Linux kernel [pdf]

Because the schedule does not provide it, here's the direct link to the talk: https://youtu.be/iffTJ1vPCSo

>"UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel"

Does anyone know how they were able to compare the size of the codebase given that UEFI is proprietary/closed-source?

Video of the talk was posted yesterday: https://news.ycombinator.com/item?id=15572978

dotTK, now there is a TLD I haven't seen in a loong while

What is Apple’s privacy reasoning for accepting UEFI?

On the other hand, isn't quite a lot of the code in Linux kernel for the same thing, handling hardware complexity?

Devil's advocate: if large customers care, AMD can easily give them a "special" microcode image with it disabled. Intel does the same thing with the "High-Assurance Platform" for the intelligence community, which is effectively a ME killswitch.

However, these fixes are generally not offered to the public even when they already exist (again, see: Intel HAP).

The rules of the game are different when you're one of the Super 7 instead of just some random pleb. And increasingly those guys are no longer interested in leaving this threat vector open, which says something.

> "only privacy nerds"

There's nothing weird in caring about security.

Data in tech companies and banks is worth hundreds of millions. Attackers are therefore willing to pay millions for a ME 0-day.

Google servers and home users have very, very different privacy and security needs. The bottom line is that the biggest threat vector on most home machines is the user. Securing a PC against threats when the user installs a browser extension for coupon printing and blasts through UAC prompts without reading them is very, very different than securing a server farm.

Maybe it's time to bag the stupid X86 instruction set entirely and move to a 64-bit chip that has a sane instruction set and that embraces loyalty to the end user all the way down to the metal.

Hey there.

In snapd (which is implemented in mostly go) we have this problem a lot. The real issue is that certain system calls fail if more than one thread exists in the calling process. One of those is setns(2), as is documented in the manual page.

What I ended up doing is to use a small C preamble that parses command line arguments, figures out where to go and uses setns before the go code even begins initializing.

This solved the particular case we were working on but in my opinion golang's opinionated approach to threading is not suitable for writing many system tools in it.

My wishlist item for golang 2.x is a build mode where threading is 100% under developer control but this seems to be at odds with the design for non-blocking IO.

It sounds like the whole point of this project is to not have two separate OSes. Linux+Linux is much simpler than Linux+Minix or whatever.

> Why Linux? You already have Linux for OS, why the same on firmware?

The Linux they're flashing to the firmware ROM is a custom minimal build. Using that, they can then boot a standard distro kernel. And depending on your threat model, you might not need to update the firmware kernel as often as the distro kernel, as it's only used for booting. Note that this is for servers; for an embedded system you might as well boot directly to the final kernel.

> Why not Minix? ( Used in Intel Me Already ) Why not OpenBSD? ( Very Secure ) Why not NetBSD? ( Extremely Portable ) Why not FreeBSD?

A few guesses:

- Linux is the one most familiar to the developers of this. And to the Google sysadmins, presumably.

- Compatibility: If the distro kernel resides on, say, an XFS filesystem on an MD-RAID device, the firmware boot kernel needs drivers for that.

- It uses kexec which is a quick and easy way to boot a Linux kernel from another Linux kernel. If you want to boot from another OS you'd have to figure out something else.

> Why not Coreboot?

Coreboot is preferable, but since the low-level firmware on modern x86 server platforms is tightly controlled with hardware signing keys, no data sheets released etc., coreboot hasn't been able to run on an Intel x86 server platform for the past decade. This project (NERF) is a pragmatic compromise, by replacing only the upper parts of the firmware stack and removing/disabling the ME as much as possible.

> Why not the OpenSource UEFI implmentation?

It's designed-by-committee crap which is far less battle tested than Linux.

> Why not switch back to simple and easy BIOS?

It's less evil than UEFI sure, but I guess it's unfortunately only a question of time until it's removed from PC firmwares (Apple already did it many years ago, AFAIU). Besides, AFAIK switching to BIOS mode does nothing to disable the ME.

And if you're going to do something from scratch, you might as well use something sane like coreboot.

There's also Open Firmware.[1] Sun and Apple used to use that.

[1] https://en.wikipedia.org/wiki/Open_Firmware

I watched the talk video and I don't remember it was stated anywhere that Google will replace UEFI/Intel ME. The correct title is "Replace your exploit-ridden firmware with a Linux kernel".

> Doesn't Coreboot implement UEFI?

No. Though I think there is some work to allow people to build a coreboot + upper layers of UEFI (presumably using the open source tianocore UEFI implementation) combination in order to boot operating systems that require UEFI. Just like it's possible to build a coreboot + seabios combination in order to boot OS's that require BIOS services (such as DOS).

> nonetheless, the idea of putting a full Linux kernel in the firmware (if I'm reading the article correctly), presumably just to boot another one in the actual OS, despite the openness, sounds like it would increase complexity even more.

UEFI is very complex. I.e. it contains a TCP/IP stack (v4 & v6), and whatnot. The Linux IP stack is certainly a lot more battle tested than the UEFI one. And further, the idea is to allow the owner of the hardware to update the boot Linux kernel and not be beholden to the whims of the Intel & the HW manufacturer, who may not have the owners interest as a primary concern.

No, UEFI actually leaves components running after the OS boots. This talk discusses how to replace the proprietary UEFI BootManager with a Linux kernel, and then uses it kexec the Linux kernel from the boot device.

Over 20 years ago, we had MILO, the "mini-loader" for DEC Alpha machines that was a Linux kernel used as a bootloader to find the real Linux kernel we'd then boot. In that case, it would initialize built-in device drivers to be able to use the network or the block devices, load another kernel file into RAM, and then kexec the new kernel and disappear until the next system reset.

It is an interesting wrinkle to ponder leaving such an embedded kernel running in place of UEFI or other SMM hypervisors. Should there be a new syscall layer between the two kernels, or are current SMM traps, ACPI, and UEFI constructs really the right way to do it, even if the same open source community is in charge of both layers?

However, a general practice has been that the firmware loaders would be replaced less often and stick with "known good" versions, while the booted kernel could be updated more often. But in this new and threatening world, the firmware kernel can be "known bad", so you need a way to push out updates frequently. You also need a fairly good fail-safe technique to recover when the new update isn't so good after all. And you need to avoid solving this problem with yet another firmware layer which lets you choose between your firmware copies, but itself can be compromised and cannot be easily patched...

I don't think much is publicly known about Apple's UEFI implementation; what if it's already stripped down?

Yeah, but it's also extremely common to conflate those two. It's not as bad as how everything was somehow a "zero day" for a few years there.

Backwards compatibility is a big reason. If the OS handles everything then you can only use an OS that has the latest drivers. Driver bugs could also brick your hardware in some cases.

There is actually an significant technical issue with user-supplied microcode on modern fast CPUs: the control store is not fully writable and only small parts of it can be patched in the field. Reason for that is that the control store is probably the fastest block of memory in modern PC as it has to have latency on the same order as CPU clock period and usually has very wide data bus. Implementing this as entirely writable RAM would be uneconomical.

ISH: Integrated Sensor Hub

IE: Innovation Engine

There's also the PCU Package/Power Control Unit that no one talks about.

AFAIU at this point it's quite early, and the way they're working on it at the moment is to remove the ROM flash chip (which, depending on the motherboard, may require desoldering the chip) and flash it with a SPI programmer.

If you're up to that stuff, I think they'd be happy to have your help. Otherwise maybe you should wait and hope they'll figure out how to flash it from Linux, and make it robust enough that there's a relatively low risk of bricking your system.

I think grub would usually be called after the boot firmware (like UEFI, or coreboot, or a traditional BIOS) has already initialized the hardware. Some of these systems can also directly load your operating system, and I would guess the one of the few thing missing from the boot firmware would be the filesystem support, and not much more

If I understand correctly to make it more auditable. Still: tool-chain remains prebuilt and trusting trust issues. More auditable is better than less auditable.

Parts of Intel ME are probably derived from Minix 3.

http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-an...

Linux has undergone a lot more (hostile and friendly) penetration testing and bug-fixing than UEFI.

The other one is also open source (maybe a bit less). However Linux should be a bit less exploit-ridden