20 years of beyond bios

"Beyond BIOS: Developing with the Unified Extensible Firmware Interface" https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908

reaches its twenty year anniversary 

this month. Yet another decade-counting https://vzimmer.blogspot.com/2014/01/advances-in-platform-firmware-beyond.html exercise it seems. 

The book came out of a practical need: EFI (then transitioning to UEFI) had a specification, but no single reference that walked a systems programmer from the metal up through protocols, drivers, and the security model. The UEFI spec https://uefi.org/specifications was (and is) comprehensive and precise, but at ~2,000 pages in 2006 it was not a learning document. We wanted something a firmware engineer new to the ecosystem could actually read cover-to-cover.

Looking back at what the ecosystem looked like in 2006 is instructive. The Unified EFI Forum had just been formed (2005). EDK2 as an open-source project didn't exist yet — EDK (the first-generation toolkit) was the state of the art. Secure Boot wasn't in the UEFI spec. IPv6 network boot wasn't in the spec. The notion of UEFI as the firmware substrate for ARM and RISC-V platforms would have sounded speculative. The footprint of the then-current EFI reference implementation was a fraction of today's EDK2's multi-million-line codebase shipping on essentially every server, PC, and an increasing number of embedded and mobile platforms.

The subsequent editions in 2010 and 2017 tracked the evolution: a second edition https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ added Secure Boot and more on the PI (Platform Initialization) spec work. After Intel Press shut down in the mid 2010's, DeGruyter https://www.amazon.com/dp/1501514784 picked up the third edition in 2017. DeGruyter is Eur

**What held up**

The architectural framing — protocols as the unit of interface abstraction, the PI phases (SEC, PEI, DXE, BDS, RT) as the organizing principle, handles and GUIDs as the extension mechanism — held up remarkably well. UEFI is accused of complexity, sometimes fairly, but the core services and driver model are coherent and the spec has maintained backward compatibility across 20 years in a way that is genuinely difficult to achieve (maybe 25+ years if you consider EFI1.02 and elide things like device i/o protocol).

The security chapters aged less well, which is entirely predictable in retrospect. We knew that SMRAM needed stronger isolation guarantees. We didn't fully anticipate the firmware attack surface becoming a primary target for advanced persistent threat actors. The years between 2006 and the NIST SP 800-147 guidance https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-147.pdf in 2011 represented a period where the attack surface was well ahead of the defensive specification.

It was probably a wise choice not to read in too much on the open source. Although De Gruyter has been around since the mid-1700's, it's beaten by Springer Verlag that has been publishing since the late 15th-century. And APress (a Springer imprint) has been where you see more implementation-focused books https://link.springer.com/search?query=&content-type=Book&dateFrom=&dateTo=&contributor=Vincent+Zimmer&sortBy=newestFirst. 

I joke to myself that all of these books are BG, or "Before GPT." Now that we are in the AG or "After GPT" era does anything read these tech books (other than models integrating them in their training data set)?  You still need code to realize these solutions, so maybe Rust docs, Git books, and other literate programming approaches where the documentation lives with the code in live repo's is the way to go. 

**What's different in 2026**

I have always felt that the specification needed to be more precise than prose allowed. The evolution from "here's what the spec says in English" to "here are the machine-checked invariants the implementation must maintain" is the direction the field needs to move https://beneficial-ai-foundation.github.io/SVIL2026/. And moving from C (where you can drop CBMC and Frama-C) to Rust (where you have Kani, Verus, Aeneas) goes hand-in-hand with that evolution. Or maybe the TCB is too large and more focused art like DRTM will prevail for aspects of the boot chain that need more assurance?  Or everyone will build their own bespoke stack and have a variant of a vertically-integrated iBoot-style solution? Twenty years from 2026 will be interesting.

Wind Energy and the Long Arc: December 1990

December 1990. I was a senior at Cornell (well, really a junior), and the Cornell Engineer magazine published a piece on wind energy that I was involved with. That issue has been sitting in a drawer — or rather, stored as a scan that I apparently fed into the scanner upside down — for the better part of 36 years. I finally rotated the pages, posted the PDF to https://github.com/vincentjzimmer/Documents/blob/master/Wind_Energy_Cornell_Engineer_December_1990.pdf, and thought a few words were warranted.

Wind energy in 1990 was a niche topic in a way that's almost hard to remember now. The wind farms of Altamont Pass in California https://en.wikipedia.org/wiki/Altamont_Pass_Wind_Farm had been operating for about a decade — the first commercial-scale wind farm in the U.S. had come online in 1981 — but the economics were marginal and the technology was adolescent. The phrase "renewable energy" had not yet acquired its current ubiquity. Horizontal-axis turbines were winning out over vertical-axis designs https://en.wikipedia.org/wiki/Darrieus_wind_turbine, but the engineering was still very much in flux.

Cornell was a good place to be thinking about this. The College of Engineering had people working on structural dynamics, aerodynamics, and the applied mathematics that underpins both. The Cornell Engineer was student-run and gave us latitude to write about topics that weren't necessarily part of our coursework.

I graduated in early 1992 and spent the subsequent 30+ years doing systems software — firmware, UEFI, formal verification, very far from wind turbines. But there's a through-line that I think about occasionally: the engineering problems that look straightforward from a distance become deeply interesting at the interface of physics and constraints. Wind turbines in 1990 were a blade-structure-aerodynamics-economics system, the kind of coupled-domain problem that doesn't submit to clean reductionism. Firmware is a CPU-platform-specification-security system with the same character.

The other through-line is time. Wind energy from a marginal 1990s technology to >10% of global electricity generation https://ember-energy.org/latest-insights/global-electricity-review-2025/ took about 35 years of sustained engineering, policy, and economics. A lot of the infrastructure that enabled it — power electronics, grid-scale storage, turbine materials — was being worked out in parallel by people who weren't waiting for a clean solution to arrive. That's also how firmware security works, and how formal verification of systems software is working right now.

The upside-down scan is an apt metaphor. Sometimes the record needs a 180° rotation to be readable.

And it looks like some things don't change, either. 

Vincent Quixote?