The Linux Foundation
6 HN recommenders · recommended in 7 months, 2017–2023
38:03 · 73K views · Oct 27, 2017
Ronald Minnich of Google explains how UEFI firmware is a large closed attack surface and describes Google's work replacing it with Linux-based boot firmware. It also touches on Intel ME and other security coprocessors.
Recommended as the go-to talk on firmware security risks, Intel ME, and why replacing UEFI with Linux speeds up and hardens boot.
12 comments from Hacker News
Intel CSME (formerly ME) and AMT ST (formerly PSP) have many properties that are / would be desireable for someone who is/was building a backdoor (DMA, TCP/IP stack that can use onboard ethernet without the host OS being aware, closed source, unremovable, etc). Keep in mind that even if there has not been a backdoor deliberately added, there absolutely have been serious exploits in ME and PSP, and even for those who are not worried about the government, these security coprocessors still pose grave risk to data privacy and security, potentially handing "ring -3" access to non-government hackers. While I personally share your belief that these are probable backdoors, it is important to remind skeptics that they pose a grave security and privacy threat even outside the context of a government backdoor conspiracy. There's a great talk on the risks posed by the capabilities of these security coprocessors by an extremely well-versed individual at Google who was (leading? involved at a high level?) working on Google's efforts to neutralize these dangerous subsystems at Embedded Linux Con in 2017: this video
Absolutely fantastic video from a google engineer (and the original author of LinuxBios / Coreboot) on how they replaced the UEFI firmware with Linux to get Dell servers to boot in 20 seconds: this video
The gist is (which doesn't hold universally true), when the CPU is powered up, it initializes its internal RAM, loads in a pre-boot ROM, executes it. pre-boot ROM's job is to initialize whatever it has to, to bring in the initial bootloader which initializes RAM, finds a suitable bootloader program and loads it in. This program, also called second-stage bootloader , is an Operating System in its own right. It can understand filesystems, explore attached hardware, speak multiple network protocols, initialize devices as needed. The second-stage bootloader (there may also be a third-stage ) usually then boots into a Kernel. The Linux Kernel invokes the init process and things proceed into the userspace from there. At each of those stages, the bootloader images, the kernel image, the device trees, and the disk / filesystem are verified ("measured") for integrity eventually anchored on a "hardware root-of-trust". If you're a visual learner: How TI Beagleboard boots (33m): [LINK] / [LINK] How ARM Cortex M boots (9m): [LINK] / [LINK] Bootloader 101 (embedded devices; 38m): [LINK] / [LINK] Measured Boot (39m): [LINK] / [LINK] Coreboot (38m): this video / this video U-Boot (1h 25m): [LINK] UEFI for U-Boot (38m): [LINK] / [LINK] Device Trees (43m): [LINK] / [LINK] ARM Trust Zone (46m): [LINK]
I first heard the Minix thing in this talk: this video which I found, I think via a HN thread. Anyway, most of the articles rehash this talk and IMO its a solid 30 minute investment.
A recent talk [0] by Ronald Minnich from Google gives a nice overview of their efforts to replace parts of Intel ME and UEFI with Linux, mostly for security reasons. [0] this video