Replace Your Exploit-Ridden Firmware with Linux - Ronald Minnich, Google

The Linux Foundation

AI-assisted summary of Replace Your Exploit-Ridden Firmware with Linux - Ronald Minnich, Google — original source. Check the original for full context.

Source published: 2017-10-27

Key ideas

• Google developed NERF (Non-Extensible Reduced Firmware) to replace bloated UEFI runtimes and Driver Execution Environment (DXE) modules with a compact Linux kernel and Go-based initramfs, dropping boot times on Open Compute Project server nodes from eight minutes to twenty seconds. (0:00)
• Modern x86 hardware runs multiple hidden operating systems below Ring 0—including Minix 3 on the Intel Management Engine (Ring -3) and UEFI/SMM (Ring -2)—operating duplicate IP stacks, disk drivers, and web servers that persist across hard drive wipes. (1:46)
• By deploying the `me_cleaner` script to strip unsigned partitions down to the signed BringUP (BUP) module and toggling Intel's High Assurance Platform (HAP) bit, researchers can neutralize Management Engine network bloat without tripping the hardware 30-minute watchdog shutdown. (13:09)
• The project pairs Linux with u-root, an initramfs written in Go that compiles utilities on demand in roughly 200 ms or bundles an entire userland into a sub-2 MB BusyBox-style binary, bypassing standard bash-scripting overhead and legacy EFI signature models. (23:23)

Detailed notes

## Background Published by The Linux Foundation on YouTube on October 27, 2017, this presentation features Google software engineer Ronald Minnich discussing the security vulnerabilities exposed by proprietary UEFI firmware following the Vault 7 disclosures. The session details NERF (Non-Extensible Reduced Firmware), an open-source initiative developed at Google that replaces vulnerable UEFI runtime environments with a minimal Linux kernel and a Go-based u-root initramfs.

## TL;DR Ronald Minnich outlines how modern x86 platforms harbor hidden, proprietary operating systems beneath Ring 0—specifically UEFI in Ring -2 and the Intel Management Engine running Minix 3 in Ring -3—that pose severe persistence and exploit risks. To eliminate this attack surface, Google's NERF architecture trims the Management Engine with tools like me_cleaner, neutralizes or redirects System Management Mode (SMM), and halts the UEFI boot process immediately after early hardware initialization. NERF replaces the bloated Driver Execution Environment (DXE) and boot manager with a battle-tested Linux kernel and a memory-safe Go userland (u-root), reducing server boot times from eight minutes to twenty seconds while establishing platform auditability where coreboot is blocked.

## Atmosphere & style The presentation carries a blend of dry hacker humor and genuine technical alarm, punctuated by Minnich's wry one-liners like proclaiming it 'the year of Minix on the desktop' due to ubiquitous Intel ME chips. Speaking candidly against harsh stage lights, Minnich shares battle-tested engineering war stories from Los Alamos to Chromebooks, treating the audience of systems programmers as peers who know the pains of low-level firmware all too well. The energy shifts seamlessly from sobering revelations about unpatchable hardware cloaking mechanisms to an empowering, pragmatic showcase of reclaiming control over physical machines using Linux and Go.

## Bulletin - [00:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=0s) Google developed NERF (Non-Extensible Reduced Firmware) to replace bloated UEFI runtimes and Driver Execution Environment (DXE) modules with a compact Linux kernel and Go-based initramfs, dropping boot times on Open Compute Project server nodes from eight minutes to twenty seconds. - [01:46](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=106s) Modern x86 hardware runs multiple hidden operating systems below Ring 0—including Minix 3 on the Intel Management Engine (Ring -3) and UEFI/SMM (Ring -2)—operating duplicate IP stacks, disk drivers, and web servers that persist across hard drive wipes. - [13:09](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=789s) By deploying the `me_cleaner` script to strip unsigned partitions down to the signed BringUP (BUP) module and toggling Intel's High Assurance Platform (HAP) bit, researchers can neutralize Management Engine network bloat without tripping the hardware 30-minute watchdog shutdown. - [23:23](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1403s) The project pairs Linux with u-root, an initramfs written in Go that compiles utilities on demand in roughly 200 ms or bundles an entire userland into a sub-2 MB BusyBox-style binary, bypassing standard bash-scripting overhead and legacy EFI signature models.

## Key takeaways - [01:34](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=94s) Modern x86 systems undermine host OS sovereignty by running at least two and a half full proprietary kernels beneath Ring 0 in Ring -1, Ring -2, and Ring -3. - [02:10](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=130s) Compromised firmware achieves deep flash persistence that hard drive reformatting cannot resolve, leaving physical destruction in a shredder as the ultimate remediation. - [02:46](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=166s) The Intel Management Engine (ME) runs Minix 3 alongside co-processors like the Integrated Sensor Hub, maintaining out-of-band networking and disk control even when the machine is powered off. - [04:57](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=297s) Decades of software bloat inside the Management Engine—such as Small Business Technology and remote-management servers—have exposed machines to zero-length password vulnerabilities and millions of unpatched flaws. - [06:26](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=386s) System Management Mode (SMM) acts as a hardware cloaking device that locks away physical RAM and executes unstoppable 16-bit code outside OS visibility. - [07:59](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=479s) UEFI self-update capsules are fundamentally flawed because an entrenched in-flash exploit can simply intercept updates, report success, and maintain persistence. - [09:48](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=588s) AMD architectures do not escape closed firmware risks because Ryzen relies on the proprietary Platform Security Processor (PSP) for mandatory DRAM training. - [11:13](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=673s) NERF treats firmware extensibility as harmful, seeking to strip all post-boot runtime components from UEFI and the Management Engine. - [13:09](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=789s) Excising the Intel ME completely triggers a hardcoded 30-minute watchdog shutdown, but `me_cleaner` bypasses this by shrinking ME firmware from 5 MB down to ~300 KB by preserving only the signed BUP module. - [15:40](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=940s) Production deployments across over 100,000 Linux Networx servers historically proved that x86 hardware operates reliably with SMM completely disabled. - [17:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1020s) Because vendors keep Pre-EFI Initialization (PEI) proprietary, NERF targets the well-defined boundary between PEI and the Driver Execution Environment (DXE), directly replacing DXE and boot managers with Linux. - [23:23](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1403s) The u-root Go userland provides memory-safe system utilities in either an on-demand dynamic compilation mode (5.9 MB) or an AST-multiplexed single binary under 2 MB. - [26:49](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1609s) Unlike standard PCs using UEFI Secure Boot signature hierarchies, NERF looks toward hardware root-of-trust models anchored in the TPM similar to ChromeOS and Heads. - [28:24](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1704s) Coreboot has struggled on modern server platforms for 12 years due to locked Intel QuickPath Interconnect (QPI) specifications, making NERF a practical alternative for enterprise hardware. - [29:20](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1760s) Silicon initialization requires microcode patches to execute billions of instructions during DRAM training, making early microcode loading an unavoidable hardware dependency. - [29:52](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1792s) Replacing UEFI with Linux relies on a battle-tested kernel and compiler validated 24/7 across millions of production nodes, mirroring production strategies like IBM POWER9 firmware. - [35:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=2100s) Modern Intel architectures (Skylake and later) transitioned the ME to an x86 core running Minix 3, which can be disabled post-bringup using the High Assurance Platform (HAP) bit.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=0s) Introduction and Dramatic Boot-Time Reductions

Squinting against the stage lighting, Ronald Minnich opens by introducing his work at Google and clarifying a common misconception. For over a decade, whenever he discussed firmware, audiences reflexively assumed he was wearing his coreboot hat. He emphasizes immediately that this talk is entirely different: “I am not wearing my coreboot hat today; this is very much not a coreboot talk.” He acknowledges collaborators in the audience and across industry partners, including Jean-Marie Verdun, Guillaume, several Google teammates, Trammell Hudson from Two Sigma, and Andrey Mirtchovski at Cisco, who assisted extensively with the Go programming language components.

Minnich dives straight into the operational results, highlighting an Open Compute Project (OCP) Facebook compute node on display in their booth. By substituting standard proprietary firmware with their new architecture, the team slashed the machine's boot time from an agonizing eight minutes down to just twenty seconds. Yet Minnich downplays this dramatic metric, noting that to his way of thinking, the speedup is perhaps the single least important outcome. The real transformation lies in security, reliability, and architectural control: placing a Linux kernel and an initramfs directly inside motherboard flash, with an entirely Go-based userland (including init). This replaces legacy firmware with trusted open-source code and strips away all post-boot activities normally carried out by UEFI and Intel's Management Engine.

- **OCP node benchmark:** Boot time plummeted from 8 minutes down to 20 seconds. - **Embedded stack components:** A compact Linux kernel and initramfs stored directly in motherboard flash memory. - **Userland architecture:** Entire userland, including `init`, written purely in Go. - **Key objective:** Total elimination of post-boot UEFI runtime services and Management Engine interference.

[01:34](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=94s) The Hidden Operating Systems Beneath Ring 0

Reflecting on the early days of Linux in the 1990s, Minnich recalls when the kernel held absolute authority over classic Intel x86 hardware (like the Pentium/586). That sovereignty has vanished. Modern x86 architecture inserts at least two and a half full, proprietary operating system kernels underneath Linux. Because these subterranean systems operate at higher privilege levels than ring 0, they can arbitrarily manipulate, spy on, or control the host operating system. Minnich observes that their closed, proprietary design makes them extraordinarily exploit-friendly.

Worst of all, compromises within these lower rings achieve deep persistence. Unlike standard disk-based malware that can be eliminated simply by wiping or reformatting a hard drive, exploits targeting these low-level environments write directly to the motherboard flash. Once entrenched, an attacker cannot be easily dislodged, leaving system owners with catastrophic remediation costs. Minnich recalls an older presentation title that sums up the grim reality: “I used to give this talk and the title was 'If you trust your computer, you're crazy.'” When firmware becomes compromised beyond recovery, “maybe one of your options is you shred your motherboard because there's just no other way out of the problem.”

```mermaid flowchart TD accTitle: The Privilege Ring Hierarchy of Modern x86 Systems accDescr: Diagram illustrating the modern privilege architecture from user space down to the Intel Management Engine in Ring -3.

subgraph OS["Visible Operating Space"] R3["Ring 3: User Applications"] R0["Ring 0: Linux / Host OS Kernel"] R3 --> R0 end

subgraph Hyp["Virtualization Layer"] RMinus1["Ring -1: Hypervisor (KVM, Xen, ESXi)"] R0 --> RMinus1 end

subgraph Hidden["Hidden Firmware Layers"] RMinus2["Ring -2: SMM (System Management Mode) & UEFI Kernel"] RMinus3["Ring -3: Intel Management Engine (Minix 3 on ARC / x86)"] RMinus1 --> RMinus2 RMinus2 --> RMinus3 end ```

- **Ring 0 vs. lower rings:** Linux runs in ring 0, but ring -1 (hypervisors), ring -2 (SMM/UEFI), and ring -3 (Management Engine) hold superior system authority. - **Disk vs. flash persistence:** Disk formatting cannot remediate flash-resident firmware compromises. - **Ultimate recovery option:** Physical destruction of the motherboard in a shredder.

[02:46](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=166s) The Subterranean Hierarchy: SMM, UEFI, and Minix 3 in Ring -3

Minnich unpacks the confusing terminology of the lower rings, noting that as engineers added layers behind traditional rings, they simply ran out of numbers and adopted negative designations. Ring -2 consists of a full UEFI kernel running in 64-bit page mode alongside what Minnich categorizes as a "half kernel": System Management Mode (SMM). SMM is an ancient execution environment that halts all normal OS operations and drops the main processor into real-mode-like 16-bit 8086 code whenever triggered (such as when closing a laptop lid), completely bypassing Linux memory protections.

Deeper still sits Ring -3, the zone generating the deepest panic in modern security circles. Die-level integration on Intel platforms regularly includes three separate auxiliary microcontrollers: the Integrated Sensor Hub, the Innovation Engine (“I just every time I say that I kind of have to laugh a little”), and the Intel Management Engine (ME). The ME runs Minix 3, giving rise to Minnich's dry running joke: “and that's why this is the year of Minix on the desktop because if you add up all the nodes running Windows and all the nodes running Linux that's less than all the nodes running Minix 3.” Ring -2 and Ring -3 operate duplicate, uncoordinated implementations of complete software stacks, including distinct IP networking stacks, file systems, disk drivers, and full USB mouse/keyboard drivers. The ME possesses independent file systems and network capabilities specifically so it can reach across the network and silently re-image a workstation while it sits powered down, so long as the power cord and Ethernet cable remain attached.

- **Sub-core hardware:** Intel silicon often includes three co-processors running alongside the main x86 cores (Management Engine, Integrated Sensor Hub, Innovation Engine). - **Embedded OS deployment:** Intel ME runs the Minix 3 operating system across hundreds of millions of manufactured chipsets. - **Duplicate stacks:** Ring -2 and Ring -3 run independent networking, USB, and file system stacks completely invisible to Linux. - **Out-of-band power:** ME maintains network connectivity and disk control even when the host system is powered off.

[04:57](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=297s) The Threat Landscape: ME Bloat and Decades of Vulnerabilities

Minnich reviews the bizarre assortment of software modules bundled inside the Management Engine binary blob. These include distinct flavors of network manageability, Small Business Technology, the "Outbreak Containment Heuristic" (a moniker that Minnich quips sounds like a Hollywood thriller), and the Protected Audio Video Path (PAVP), which provides hardware-enforced DRM. Regarding Small Business Technology, Minnich notes that its original implementation ten years earlier sidestepped credential setup entirely: “what Small Business Technology meant originally about 10 years ago is it's really inconvenient to set up passwords, so we just don't have a password for the ME.”

This software bloat produces catastrophic vulnerabilities. Minnich cites Vasilis Pappas's comprehensive master's thesis written a decade earlier that documented widespread, systemic vulnerabilities across ME modules, many of which lingered unfixed. More recently, Intel had to patch an egregious remote-access flaw that permitted unauthenticated administrative control via a zero-length password string sent to the ME's internal web server. A basic search for "Intel ME exploit" surfaces over 50 million results, with Minnich pointing to a *Wired* headline reporting that Intel had finally resolved an issue that persisted unpatched for seven years. Affecting up to a billion machines, the nominal vendor remediation is simply telling consumers to update their firmware. Minnich expresses total disbelief that any meaningful fraction of that hardware has actually received updates: “How many people want to believe that a billion machines have been refreshed since last spring with new firmware to fix this bug? I certainly don't believe it.”

- **Unauthenticated access:** Multiple ME iterations allowed full out-of-band administrative takeover using null or zero-length passwords. - **Legacy bloat:** Includes enterprise and small-business management utilities, DRM paths (PAVP), and mysterious outbreak heuristics. - **Industry patch rates:** Despite impacting an estimated billion devices worldwide, practical firmware patch rates among end-users and data centers remain negligible.

[06:26](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=386s) System Management Mode (SMM) as a Hardware Cloaking Device

Turning his attention to the "half OS" in Ring -2, Minnich explains that System Management Mode originated with Intel 486-era laptops to handle basic hardware power management. When a user running MS-DOS shut their laptop lid, the operating system had no native power-management logic to put the machine to sleep; engineers created SMM to seize control of the machine behind the OS's back using System Management Interrupts (SMIs). Over time, vendors exploited this mechanism for all manner of silent background tasks, such as injecting transparent USB mouse emulation into older operating systems lacking native USB stacks.

The fatal architectural flaw of SMM is its irreversibility and opacity. Once enabled during the initial boot sequence, the platform sets a hardware configuration bit (such as SMRAM lock) that permanently walls off a large chunk of physical memory, rendering it completely invisible and inaccessible to Ring 0. Minnich describes this hidden RAM segment as an unstoppable hardware cloaking device: “so it kind of it's a cloaking device, right? It just vanishes this memory with its stuff in it, so you kind of can't really know what it's going to do, you can't disable it, you can't turn it off, and it's hidden.” Because software running in Ring 0 cannot audit, modify, or terminate code running in SMM, hardware vendors retain permanent, unaccountable control over the execution state of the processor.

- **Origin:** Introduced on the Intel 486 to provide OS-agnostic power management for primitive environments like MS-DOS. - **Trigger mechanism:** System Management Interrupts (SMIs) suspend host CPU execution instantly. - **Cloaked memory (SMRAM):** Hardware locking bits render the SMM RAM region invisible to ring 0 Linux and host introspection tools. - **Unstoppable execution:** Once initialized at boot, SMM cannot be switched off or audited by the host operating system.

[07:59](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=479s) The Complexity and Unpatchable Trap of UEFI

Minnich addresses the other half of Ring -2: the Unified Extensible Firmware Interface (UEFI) environment executing on the main CPU. UEFI represents an immense, highly complex operating system kernel. Firmware engineers working for board manufacturers and third-party vendors are tasked with writing drivers against this arcane framework without fully understanding its labyrinthine architectural rules, inevitably introducing severe security flaws: “and the result is that there are big giant holes that people can drive exploits through.” When surveying the conference room, Minnich asks how many attendees have authored UEFI code. Seeing a substantial show of hands, he asks if they enjoyed the experience; reading their faces, he chuckles, “Okay, so I never liked it personally.”

The foundational security failure of UEFI centers on its flawed self-update paradigm. The design operates on the naïve assumption that the firmware environment is completely trustworthy and intelligent enough to safely update itself: a host kernel drops an update payload into RAM, trips a notification, and expects UEFI to parse and flash the new code bug-free. Minnich points out that if a machine has already been compromised by an in-flash UEFI rootkit, requesting an update accomplishes nothing. The malicious UEFI binary merely returns success while preserving the exploit intact in flash: “so the worry has been that you can make an exploit that can't ever be removed and again the only remediation is a shredder.” Examining the component manifest of even a stripped-down OCP compute node reveals a sprawling attack surface loaded with redundant IP stacks, USB stacks, and obsolete legacy drivers like ISA bus support that have no place in a modern production server.

| UEFI Component Category | Embedded Implementation | Architectural Risk Identified by Minnich | |:--- |:--- |:--- | | **Network Protocols** | Dual IPv4 and IPv6 stacks | Unaudited, network-facing attack surface executing before and underneath the operating system. | | **Bus Drivers** | Legacy ISA bus support | Superfluous legacy code shipped by default on modern data-center compute nodes. | | **I/O Protocols** | Proprietary USB stack | Independent peripheral parsing running with root-level privileges; vulnerability to malicious USB payloads. | | **Self-Update Framework** | In-band capsule / runtime flash updater | Once compromised, rogue firmware can intercept update hooks, report success, and persist forever. |

[09:48](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=588s) The Threat of Hidden OSs and the Myth of AMD Safety

Firmware environments like UEFI are bloated with primitive drivers—legacy IDE support, polling I/O routines, and artificial delays—which Minnich points to as the primary reason machines boot so terribly slowly. Compounding the latency, modern systems harbor roughly "two and a half hidden OSs" running beneath the user's control. These hidden layers possess independent network stacks, embedded web servers, and self-modifying code that survives power cycles and operating system reinstalls. They are prone to security bugs, have full visibility into the running OS, and have already been subject to documented real-world exploits. In earlier versions of his presentation, Minnich would conclude right here with a stark warning: “If you're not scared yet maybe I didn't explain it very well because I sure am scared.”

```mermaid flowchart TD accTitle: Two and a Half Hidden Operating Systems accDescr: Diagram illustrating hidden firmware layers that control and persist beneath the main operating system. subgraph Host ["Visible Host System"] OS["Linux / User OS"] end

subgraph Hidden ["Hidden Firmware Layers"] SMM["Ring -2: System Management Mode (SMM)"] ME["Ring -3: Intel Management Engine (ME) / Minix 3"] UEFI["UEFI Runtime / Driver Execution Environment"] end

ME -->|"Controls clocks, reset vector, DRAM"| Host SMM -->|"Traps execution, inspects memory"| OS UEFI -->|"Persists across reboots, runs alongside OS"| OS ```

When addressing how to remedy this architecture, Minnich refutes the common community belief that switching to AMD hardware solves the problem. While AMD was more open in past eras, modern architectures like Ryzen cannot simply be dropped in as an open alternative. AMD moved the obscure, sensitive initialization tasks formerly in EFI over to the Platform Security Processor (PSP). It is the PSP—not the main x86 CPU—that initializes DRAM, and AMD will never release the proprietary PSP code required for that memory training. While AMD might offer open interfaces in certain areas, Minnich summarizes the reality bluntly: “Kind of AMD is more open in the things that are open, but it's not open in a sense of things closed on Intel are still things closed on AMD if that makes any sense.”

- UEFI contains archaic, polling-driven drivers full of hardcoded delays that severely degrade boot performance. - Hidden firmware operating systems run independent IP stacks, host web servers, and persist malicious code across drive wipes and power cycles. - AMD Ryzen systems rely on the proprietary Platform Security Processor (PSP) to bring up DRAM, keeping key boot stages completely closed.

---

[11:13](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=673s) Introducing NERF: Non-Extensible Reduced Firmware

Focusing primarily on Intel x86 due to personal use and server ubiquity—while noting the concepts transfer over to AMD architectures outside of the Management Engine—Minnich introduces the NERF project. While UEFI stands for Unified Extensible Firmware Interface, Minnich and his team hold that extensibility in firmware is an active hazard: “We consider extensibility harmful, so NERF stands for Non-Extensible Reduced Firmware.” The mission of NERF is to severely reduce the attack surface of firmware, strip out runtime components from both the Intel Management Engine (ME) and UEFI, eliminate network stacks and web servers, and completely revoke firmware's ability to reflash itself.

Firmware flashing should be mediated by the primary operating system, exactly as proven by Google's Chromebook ecosystem. With upwards of 30 million Chromebooks in active use, firmware updates are applied directly by Linux itself, eliminating the machine-bricking bugs historically seen when UEFI handled flash routines. The architectural blueprint of NERF comprises four distinct layers: a de-blobbed Intel ME ROM, a UEFI ROM stripped to its bare initialization minimums, the elimination or vectoring of System Management Mode (SMM) into Linux, a tiny Linux boot kernel, and a lightweight userland written in Go. Minnich invites Go developers to contribute, highlighting that participating in NERF does not strictly require deep firmware or kernel expertise due to the substantial Go-based userland effort.

- **NERF definition:** Non-Extensible Reduced Firmware, designed to eliminate hidden runtimes and firmware attack surfaces. - **Flashing safety:** Proves firmware should be written by Linux; Chromebooks deploy Linux-managed bios reflashing across 30+ million devices without UEFI-style bricking incidents. - **Four core pillars:** 1. De-blobbed Intel ME ROM image. 2. Minimalist UEFI hardware-init foundation. 3. SMM disabled or trapped directly to the Linux kernel. 4. Linux kernel paired with a Go userland (u-root).

---

[13:09](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=789s) Taming the Intel Management Engine with `me_cleaner`

Eliminating the Intel Management Engine entirely is an engineering impossibility because it is hardwired into the silicon die. When system power is applied, the ME engine powers on first, starts the hardware clocks, and supplies the reset vector to the main x86 CPU. If an administrator deletes the ME firmware wholesale, the board will refuse to boot or will shut down after exactly 30 minutes—a watchdog timeout triggered by the ME when it detects its firmware is broken and assumes it has granted a recovery window. However, investigative work sparked by Trammell Hudson and later expanded by Nicola Corna with the Python utility `me_cleaner` cracked the firmware structure open.

On compact platforms like the $159 MinnowBoard MAX, the onboard 8 MB SPI flash allocates 5 MB exclusively to the Intel ME. Running `me_cleaner` against this image strips that 5 MB footprint down to a mere 300 KB, removing the internal web servers and networking code while retaining just enough initialization logic to start clocks and boot Linux. Minnich cautions that server platforms present unique hurdles; running `me_cleaner` on Open Compute Project (OCP) server nodes breaks boot. Analyzing the partitions reveals that while the MinnowBoard only needs a single partition (such as `BUP`, the boot-up kernel likely running Minix 3 alongside partitions like `POLICY`, `RSA`, and `FPM`), OCP server firmware contains duplicate `BUP` modules where `me_cleaner` strips critical dependencies after the initial boot stage.

```mermaid flowchart LR accTitle: me_cleaner Flash Footprint Reduction accDescr: Visual comparison showing how me_cleaner reduces a 5MB ME partition down to 300KB on a MinnowBoard MAX. subgraph Original ["Original 8MB SPI Flash"] A["Intel ME Firmware: 5.0 MB (Web server, IP stack, BUP, RSA)"] B["UEFI / Host Code: 3.0 MB"] end

subgraph Cleaned ["Cleaned Flash via me_cleaner"] C["Minimal ME (BUP): ~300 KB"] D["Freed Flash Space: ~4.7 MB"] E["UEFI / NERF Payload: 3.0 MB"] end

Original -->|"me_cleaner processing"| Cleaned ```

- Completely excising ME bricks the platform or triggers an unskippable 30-minute hardware watchdog power-down. - On the MinnowBoard MAX, `me_cleaner` slashes Intel ME firmware from 5 MB down to ~300 KB. - Cleans out known high-risk zero-day targets including the ME's internal RSA routines and networking implementations. - OCP server boards fail to boot under current `me_cleaner` logic due to multi-stage `BUP` modules, marking an ongoing engineering focus.

---

[15:40](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=940s) Defeating System Management Mode (SMM)

System Management Mode (SMM) is another privileged execution ring that Minnich targets for neutralization. If a replacement operating system enters execution early enough in the boot flow, it can disable SMM locks entirely. Countering vendor claims about SMM's absolute necessity, Minnich recalls running high-performance clusters without SMM decades ago during the LinuxBIOS era at Los Alamos National Laboratory: “We had a nice conversation once with an x86 vendor who claimed that it was impossible to run a server node with SMM turned off, and we said, 'Well, you'll have to talk to Linux Networx about their 100,000 servers they've sold with SMM turned off and explain to them that it can't work, but it's working fine for us too.'”

Vendors primarily utilize SMM to implement proprietary "value-add" features that effectively enforce vendor lock-in. For edge cases where a motherboard truly depends on SMM—such as specific hardware error handling like Single Error Correction / Double Error Detection (SECDED) interrupts—Minnich built alternative hooks to redirect the System Management Interrupt (SMI) directly into the Linux kernel. Rather than disappearing into opaque, chipset-level black-box code, SMIs can be handled like standard hardware interrupts directly inside Linux, ensuring that the primary kernel maintains absolute authority over the machine.

- SMM is not mandatory for stable x86 server operations, as proven by 100,000+ Linux Networx production cluster nodes. - Vendor defenses of SMM often boil down to proprietary differentiators and hardware lock-in mechanisms. - NERF either disables SMM completely during early handoff or vectors SMIs into standard Linux kernel interrupt handlers.

---

[17:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1020s) Replacing the UEFI Driver Execution Environment (DXE) with Linux

UEFI is so vast and intricate that its codebase forms a substantial operating system in its own right, loaded with curious artifacts (including internal sensors humorously mislabeled as a "digital thermometer"). Under a standard boot flow, UEFI executes a proprietary Security (SEC) and Pre-EFI Initialization (PEI) phase in 16-bit mode to train the CPU, chipsets, and motherboard. Minnich acknowledges that vendors guard this early phase tightly and will not open it. However, the interface between PEI and the next stage—the Driver Execution Environment (DXE)—is rigorously defined and uniformly implemented across the industry.

```mermaid flowchart TD accTitle: Standard UEFI vs. NERF Boot Execution Flow accDescr: Comparison of standard UEFI DXE phase loading OS-present runtime versus NERF swapping the boot manager for Linux. subgraph EarlyPhase ["Proprietary Hardware Bring-Up"] SEC["Security (SEC) Phase: 16-bit entry"] --> PEI["Pre-EFI Initialization (PEI): CPU/Chipset/Board Init"] end

subgraph StandardDXE ["Standard UEFI Architecture"] PEI -->|"Well-Defined Interface"| DXE["DXE Drivers (Network, Storage, IDE)"] DXE --> BM["Boot Manager (e.g., GRUB / Windows Loader)"] BM --> OS1["Target OS (Linux / Windows)"] DXE -.->|"Persists in background"| Runtime["UEFI OS-Present Runtime (Ring -2)"] end

subgraph NERFDXE ["NERF Architecture"] PEI -->|"Same Well-Defined Interface"| LinuxKernel["Linux Kernel + u-root (Go Initramfs)"] LinuxKernel -->|"Replaces DXE, Boot Manager & Runtime"| FinalOS["Kexec to Final Target OS"] end ```

In standard UEFI, the PEI phase hands off to numerous DXE drivers (network stacks, disk drivers, display protocols) that loop back and forth until the Boot Manager (such as GRUB) is invoked. Critically, standard UEFI retains an active runtime payload that lingers in memory alongside the operating system—a permanent Ring -2 hypervisor that Minnich rejects: “When Linux is running, EFI is running, and that's the thing we don't like; that's the thing we're trying to get rid of.” Because the DXE boot manager matches a clearly documented specification, NERF exploits this exact seam: it compiles an actual Linux kernel to match that well-defined handoff interface, strips out the DXE drivers and boot managers, and replaces the BIOS payload directly with Linux.

- UEFI contains a kernel codebase that rivals the Linux kernel in volume and complexity. - Early initialization (SEC and PEI phases) remains locked behind vendor NDAs, but exposes a strict, clean handoff into DXE. - Standard UEFI DXEs launch an "OS-present runtime" that continues executing concurrently with Linux post-boot. - NERF replaces the entire DXE driver loop and boot manager with a tailor-made Linux kernel that boots directly from the PEI interface.

[19:46](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1186s) Slashing Boot Times and Transitioning from UEFI to Linux

Most users recognize the conventional PC boot process by the familiar configuration screen prompting for boot device selection and system time. In NERF, that entire phase is superseded by launching directly into a Linux kernel. On the test node Ron Minnich evaluated, this transition takes roughly 20 seconds—a figure re-timed just the day prior—replacing vendor boot cycles that previously dragged on for eight minutes. Once inside the Linux kernel, system initialization drops into a Go-based user space. Its default sequence executes `dhclient`, retrieves the target kernel image via `wget`, and immediately executes `kexec`. This entire userland network boot cycle takes roughly three seconds over a 100-megabit connection linked to a Raspberry Pi.

```mermaid flowchart TD accTitle: NERF Boot Flow from Hardware Initialization to Final OS accDescr: Flowchart illustrating the early Pei and Dxe core initialization leading directly into a small Linux kernel and Go userland before kexec.

subgraph EarlyStage["Early Firmware (PEI Core)"] A["Hardware Init & Memory Training"] B["Basic Silicon Init"] A --> B end

subgraph NERFStage["NERF Execution"] C["Cut off DXE Drivers & UEFI Runtime"] D["Boot Tiny Linux Kernel (20s)"] E["u-root Initramfs (Go Userspace)"] F["Run dhclient & wget Kernel (~3s)"] B --> C C --> D D --> E E --> F end

subgraph TargetOS["Operating System"] G["kexec into Production Kernel"] F --> G end ```

Minnich explains that pressure and feedback from Trammell Hudson substantially altered the direction of his presentation compared to just a week earlier. Hudson pointed out that parts of the DXE core exist in open-source form and could be swapped out directly. Consequently, the team decided to adopt an open-source DXE replacement, lightly modified to initialize hardware and jump into Linux even faster, aiming to reduce the 20-second setup down to a fraction of that duration. While acknowledging that early initialization stages like PEI (Pre-EFI Initialization) cannot be rewritten—just as modern coreboot on Chromebooks still requires proprietary binary blobs—Minnich emphasizes drawing the line directly across the DXE core:

> “So as I said we can fix this problem partially, but partial is better than nothing and we can get rid of all the runtime components that come with EFI and that’s really the goal.”

[21:36](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1296s) Automating Firmware Builds with Heads and Generic Board Support

To make firmware construction manageable across varied hardware, NERF adopts automation concepts developed by Hudson for the Heads project. Hudson engineered a series of Makefiles and scripts that automate image creation, which NERF leverages to assemble customized images for specific motherboards. The team has already validated this build framework with positive results across hardware platforms ranging from small MinnowBoards (referred to as Minimax) and Dell PowerEdge R630 servers to large Open Compute Project (OCP) server nodes.

Working at the Linux layer also mitigates the chronic hardware fragmentation that plagues low-level firmware engineering. Minnich recalls working on five successive board revisions from a single AMD vendor where every iteration used a different GPIO pin on the I/O bridge just to toggle system memory power, creating constant maintenance headaches. In contrast, once standard x86 execution reaches Linux, the platform hardware interface is consistent and functional. While the team originally anticipated having to maintain fine-tuned kernel configurations for each unique board, experience demonstrated that a single generic kernel runs equally well on both a small MinnowBoard and a massive multi-socket OCP server node. A prior complication involving vendor-tied ACPI tables highlighted by collaborator Ryan O'Leary is also receding as architecture plans evolve.

[23:23](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1403s) Building Go-Based User Space with u-root: Dynamic Mode vs. BusyBox Model

For NERF's userland, Minnich relies on `u-root`, an initiative he founded roughly six years prior after growing exasperated with repeated build breakage and tangled configuration scripts in Buildroot and BusyBox. Security teams at Google strongly favor Go over C because of its memory-safety guarantees. `u-root` supports two distinct operational modes designed to fit different constraints:

```mermaid flowchart LR accTitle: u-root Operational Modes accDescr: Flowchart comparing the dynamically compiled source mode and the AST-rewritten single binary BusyBox mode in u-root.

subgraph SourceMode["Mode 1: Dynamic Compilation (5.9 MB)"] S1["Go Toolchain + Command Sources"] S2["Boot into RAM"] S3["Compile on Demand (~200ms per binary)"] S1 --> S2 --> S3 end

subgraph BinaryMode["Mode 2: AST Multiplexed Binary (2 MB)"] B1["Go AST parses command packages"] B2["Rewrite 'package main' to 'package pkg'"] B3["Compile single binary + symlinks (~15s)"] B1 --> B2 --> B3 end ```

The first mode packages the complete Go toolchain, dependent libraries, and command source files inside an LZMA-compressed initramfs image totaling roughly 5.9 megabytes. When the system boots, commands are compiled on the fly in memory:

- On-demand compilation takes approximately 200 milliseconds for a tool like `bin/date`, after which execution from the ramfs is instantaneous. - Security auditors favor this dynamic mode because all operational source code remains inspectable on the booted target machine.

However, flash storage limits and slower processors (such as ARM chips) make a 5.9-megabyte payload and JIT compilation impractical. For those environments, `u-root` provides a BusyBox-style multiplexed mode: - The Go abstract syntax tree (`go/ast`) package inspects utilities written as `package main` (such as `ls`) and rewrites them into standalone internal subpackages (e.g., `package ls`). - All tools are compiled together into a single multi-call binary dispatched by checking `os.Args[0]`, driven by symlinks. - A 15-second build produces a stripped payload under 2 megabytes, completely eliminating cross-compilation toolchain hassles because the Go compiler natively targets any foreign architecture simply by specifying `GOARCH`.

This architecture collapses complex SysV or systemd startup configurations into one or two readable Go binaries. Boot times drop precipitously; Minnich notes a separate Chromebook experimental build using this architecture that boots all the way into an X11 desktop and web browser in just five seconds. For systems scripting, Minnich remarks:

> “I stopped writing bash scripts years ago I just write go programs it’s actually easier and more reliable.”

Looking ahead to 2018, the project aims to partner with enterprise vendors to ship commercial server nodes pre-equipped with NERF, satisfying demands for firmware that is auditable, secure, and fast.

[26:49](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1609s) Q&A: TPM, Verified Boot, and Heads Integration

Fielding an audience question regarding security verification, Minnich clarifies that NERF explicitly rejects UEFI Secure Boot mechanisms in favor of alternative platform trust designs. Instead, the initiative looks toward the hardware root-of-trust models deployed in ChromeOS:

- While `u-root` includes an experimental verified boot implementation written in Go, Minnich candidly notes that it is currently non-functional. - Production designs will prioritize the Google Chromebook methodology for anchoring trust inside the TPM rather than legacy EFI signature chains. - Minnich admits his own limitations regarding measured boot cryptography, deferring platform measurement strategies to Hudson's work on Heads:

> “Tram is very concerned about this, Heads is part of a secure environment that he’s building, and he really has a much better understanding of measured boots than I do so to some extent I’m going to follow his lead.”

[28:24](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1704s) Q&A: NERF vs. coreboot and the Reality of Intel Microcode

An attendee questions the absence of coreboot in the presented architecture. Minnich underscores that coreboot remains his platform of choice whenever feasible, noting that he continues to run coreboot on hardware platforms like the MinnowBoard. However, modern enterprise silicon architecture has systematically locked independent firmware out:

> “Coreboot has not been on server platforms for 12 years because of this problem, because we couldn’t get the information on how to turn on QuickPath.”

Because proprietary interconnects like Intel QuickPath Interconnect (QPI) lack public programming specifications, porting native coreboot to enterprise motherboards has been completely blocked. NERF bypasses this impasse by reusing existing vendor hardware initialization while reclaiming the upper firmware layers:

- If coreboot is supported on a system, operators should use coreboot; if locked into restrictive server platforms, NERF provides the practical open-source alternative. - Addressing a final question regarding Intel microcode updates, Minnich clarifies that silicon constraints enforce vendor microcode loads during the PEI stage. On modern processors, basic DDR DRAM initialization and bus training require roughly one billion processor instructions and fail to function unless CPU microcode patches are applied beforehand, making early microcode loading an unavoidable silicon requirement.

[29:52](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1792s) Microcode Limitations and Vendor Implementations of UEFI

Ron Minnich wraps up a point about early hardware bring-up, noting that DRAM initialization must happen correctly before entering the DXE (Driver Execution Environment) stage, meaning there is simply nothing that can be done about CPU microcode in this context. Opening the floor to questions, an audience member challenges Minnich's critique of UEFI. The attendee points out that many of the egregious firmware issues Minnich complained about are not part of the core EFI specification itself, but rather stem from sub-optimal or outright horrific vendor practices—such as misusing System Management Mode (SMM) for tasks that should never live in SMM, or bloating vendor EDK II builds with countless unnecessary modules when the majority of them can be compiled out.

```mermaid flowchart TD accTitle: Vendor Firmware versus NERF Linux Strategy accDescr: Comparison between standard vendor EDK II firmware builds and Google's NERF approach of booting directly into Linux.

subgraph VendorFirmware["Traditional Vendor EDK II Firmware"] VF1["Proprietary DXE Modules<br>(Closed network, storage blobs)"] VF2["Bloated Drivers & SMM Handlers<br>(Infrequently tested at scale)"] end

subgraph NERFPath["NERF Alternative Approach"] NF1["Open Source PEI Stage"] NF2["Tiny DXE Core & Minimal Drivers"] NF3["Linux Kernel & u-root Initramfs<br>(Tested 24/7 across millions of nodes)"] end

VF1 --> VF2 NF1 --> NF2 --> NF3 ```

Minnich acknowledges that while you can compile out open-source DXE drivers, proprietary vendor-supplied binary blobs—such as closed-source network card drivers—leave developers completely stuck when source code is denied. More fundamentally, Minnich defends the philosophy of replacing UEFI with Linux by looking at battle-tested scale. At a company like Google, with at least a million production machines in its fleet, the Linux kernel and its compiler are exercised and tested continuously 24/7. In contrast, standard EFI code executes only during infrequent reboots, leaving it far less rigorously validated. Minnich points out that using Linux as firmware is not unprecedented; IBM's POWER9 architecture boots Linux straight from firmware. As Minnich emphasizes: “So I think there's a really strong case to say that that kernel that is so heavily tested and made performant should be the thing I put in firmware that that's my argument here and I've had good results for that since 1999 so I'm buying that argument.”

- Vendor builds often abuse SMM and pack in unnecessary EDK II modules, but without vendor source code for hardware like NICs, users cannot compile those DXEs out. - Google’s fleet of over a million machines subjects the Linux kernel and toolchain to massive, round-the-clock testing that EFI boot code never receives. - Booting Linux directly from firmware is an established pattern outside x86, notably employed on IBM POWER9 systems.

---

[31:52](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1912s) Open-Source EDK II Packages vs. Booting Linux Post-PEI

An audience member asks about Minnich’s firmware repository and whether the team has collaborated with the EDK II Open Platform Package, which works to upstream open-source platform enablement for various ARM and x86 architectures. Minnich clarifies that while several companies and even colleagues within Google engage with that project, his personal view diverges regarding the optimal handoff point. He credits Intel for releasing TianoCore, noting that NERF actively repurposes components of it, including the DXE core and two utility programs. However, Minnich stresses that the ultimate objective is to terminate the UEFI environment as early as possible—right at the end of the PEI (Pre-EFI Initialization) stage—and transition directly into Linux rather than sustaining an extended UEFI environment.

- TianoCore open-source components, specifically the DXE core and certain utilities, are utilized within NERF. - Rather than maintaining an elaborate UEFI runtime ecosystem, NERF aims to cut over to the Linux kernel immediately following the PEI phase.

---

[32:57](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1977s) Running NERF and ME Cleaner on Everyday Notebooks

A notebook user in the audience asks whether an ordinary end user can adopt NERF without access to proprietary UEFI source code or Intel Management Engine (ME) firmware sources. Minnich confirms enthusiastically that researcher Trammell Hudson is specifically targeting laptops with this work. Users do not need vendor source code for UEFI, nor can anyone obtain Intel ME source code. Minnich explains that Intel ME firmware begins with a cryptographically signed BringUP (`BUP`) module, which cannot be modified without bricking the machine. However, the subsequent modules trailing the `BUP` module are unsigned. Tools like Nicola Corna's `me_cleaner` strip out these extraneous unsigned modules, leaving only the initial signed `BUP`.

Over the preceding two years, researchers discovered that running with only the `BUP` present allows the platform to boot and remain operational without triggering Intel's automatic 30-minute watchdog shutdown. Minnich notes that while Trammell Hudson previously faced steep obstacles attempting to port coreboot to locked-down commercial laptops due to closely held hardware specifications, the NERF approach of modifying the existing UEFI image proves much more practical and accessible. However, Minnich cautions users that the project is still in its early stages and carries the risk of bricking devices: “Now if you're going to do it make sure you're okay with the idea of turning your laptop into a brick and recovering from that because it's still early days right and anytime you do this stuff that can happen.”

```mermaid flowchart LR accTitle: Intel Management Engine Stripping with me_cleaner accDescr: Pipeline showing Intel ME partitions, identifying the signed BUP module kept by me_cleaner while removing extraneous unsigned modules.

subgraph StockME["Full Intel ME Firmware"] direction TB BUP["Signed BUP Module<br>(BringUP / Bootstrapping)"] EXTRA["Unsigned Modules<br>(Embedded Web Server, AMT, Network Stacks)"] end

subgraph CleanedME["Cleaned ME Firmware"] direction TB KEEP["Retained BUP Module<br>(Valid signature prevents watchdog halt)"] STRIP["Stripped Space<br>(All server & tracking code removed)"] end

StockME -->|"me_cleaner processing"| CleanedME ```

- Intel ME source code is completely unavailable, but users do not need it to sanitize their firmware. - The signed `BUP` (BringUP) module must be preserved to satisfy hardware signature checks, while unauthenticated trailing modules can be safely removed. - Retaining only the `BUP` bypasses the notorious 30-minute Intel power-down failsafe while eliminating higher-level ME services. - Trammell Hudson found NERF significantly easier to bring up on commercial laptops than full coreboot ports.

---

[35:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=2100s) Purism, High Assurance Platform (HAP) Mode, and Modern Chipsets

An audience member brings up Purism's announcement claiming they disabled Intel ME on their Librem notebooks, asking if that genuinely eliminates the embedded web server Minnich described. Minnich confirms this and explains the relationship between the projects: `me_cleaner` deletes the actual executable code responsible for the web server, whereas Purism went further by setting Intel's High Assurance Platform (HAP) bit—a configuration mechanism originally introduced for US government and military systems that instructs the ME to halt shortly after initialization. Minnich emphasizes that Purism's breakthrough should not be viewed in isolation, but rather as another milestone in a continuous community effort over the last two years to progressively excavate and disable Intel ME functionality.

When asked whether `me_cleaner` works on the latest Intel CPU generations, Minnich notes that firmware research progresses so rapidly that breakthroughs occur on a weekly basis, changing the technical landscape constantly. Another attendee steps up to clarify the architectural differences across processor generations. Older ME revisions operated on an obscure ARC-based RISC architecture. Beginning with Skylake and Kaby Lake, Intel shifted the ME to an x86 core running an operating system based on a Minix 3 kernel. Reverse-engineering of these newer x86 images revealed that flipping the built-in HAP disablement bit allows users to shut down the ME completely once the initial boot-up sequence concludes. With time expiring, Minnich receives the cut-off signal from the session moderators, thanks the audience, and invites the community to get involved in the open-source project: “I just I just got told in no uncertain terms to stop thanks all for attending and we again appreciate anything you want to do for this project thanks.”

| Intel ME Architecture Era | Underlying Core Architecture | Operating System | Disablement Technique | |:--- |:--- |:--- |:--- | | **Pre-Skylake** | Proprietary ARC RISC core | ThreadX / proprietary RTOS | Byte carving via `me_cleaner` to remove unsigned partitions while retaining the base signed `BUP` | | **Skylake / Kaby Lake** | x86 core | Minix 3-derived OS | Setting the High Assurance Platform (HAP) disablement bit to shut down the ME engine post-boot |

- Purism leveraged the High Assurance Platform (HAP) bit to disable ME execution post-bring-up, building upon the partition-stripping techniques of `me_cleaner`. - Starting with the Skylake microarchitecture, Intel ME transitioned to an x86 core executing a Minix-based operating system. - Security researchers analyzing the Minix-based ME discovered that setting the HAP bit shuts down ME operation immediately after system bootstrapping, successfully preventing background runtime execution.

## Notable quotes > [11:13](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=673s) We consider extensibility harmful, so NERF stands for Non-Extensible Reduced Firmware. — Ronald Minnich

> [17:00](https://www.youtube.com/watch?v=iffTJ1vPCSo&t=1020s) When Linux is running, EFI is running, and that's the thing we don't like; that's the thing we're trying to get rid of. — Ronald Minnich

## Mentioned Ronald Minnich, Google, Linux Foundation, WikiLeaks, UEFI, NERF, u-root, Go, FreeBSD, Plan 9, Blue Gene, coreboot, Harvey operating system, ChromeOS, Open Compute Project, Facebook, Jean-Marie Verdun, Guillaume, Trammell Hudson, Two Sigma, Andrey Mirtchovski, Cisco, Intel Management Engine, Minix 3, SMM, Integrated Sensor Hub, Innovation Engine, Vasilis Pappas, Wired, AMD, Ryzen, Platform Security Processor, Nicola Corna, me_cleaner, MinnowBoard MAX, Linux Networx, Los Alamos National Laboratory, Dell PowerEdge R630, Ryan O'Leary, Buildroot, BusyBox, Raspberry Pi, Heads, EDK II, IBM POWER9, TianoCore, Purism, Librem

## Video description Replace Your Exploit-Ridden Firmware with Linux - Ronald Minnich, Google

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.

About Ronald G. Minnich Ron Minnich is a Software Engineer at Google. He has contributed to many open source projects in the last several decades, including the Linux kernel (9p file system); the FreeBSD kernel (rfork); and Plan 9 (many different areas). He directed the team that ported Plan 9 to the Blue Gene supercomputers. He invented LinuxBIOS (now called coreboot) in 1999. He is one of the core contributors to the Harvey operating system. His most recent Linux Foundation talk was on how to build your own signed version of ChromeOS and resign your Chromebook with your personal keys in 2016.

[Source](https://www.youtube.com/watch?v=iffTJ1vPCSo)