Electromagnetics for the win

Now that the UW school year has commenced a spate of lectures on different topics has been posted I have the chance to take the light rail and sample the frontier of knowledge in-person at the Universit of Washington here in Seattle. For example, Smith Hall hosted an interesting talk on the Applied Math series by former Los Alamos, now Helion https://www.helionenergy.com/ scientist.

https://amath.washington.edu/calendar?trumbaEmbed=eventid%3D210915370%26seotitle%3DSeminar-in-Applied-Mathematics-Luis-Chacon-Distinguished-Theoretical-Scientist-Helion%26view%3Devent%26-childview%3D%26returnUrl%3Dhttps%253A%252F%252Famath.washington.edu%252F

on the topic of modeling plasmas. This took me back to my days as a research assistant where I developed simulations for high-power electron devices (I confess I had to remind myself of the details of that Cornell work from https://sites.google.com/site/vincentzimmer/cv). I also prototyped and modeled a device to be used as input in ferroelectrics emission research at the high energy lab.

I was amazed to hear that a lot of the basic simulation techniques like Particle in Cell (PIC) from tools I used at Cornell like Superfish https://www.osti.gov/biblio/10140823 https://www.osti.gov/servlets/purl/10140823 are still in use today. The talk mentioned how to reduce dimensionality, etc, for supercomputer runs but the basic algorithmics held. Fascinating. It appears SuperFish isn't open source but a quick web search did reveal https://github.com/OpenParEM/OpenParEM. Perhaps I'll dive back into this area if I can spare a few free hours - my Jackson 'Classical Electrodynamics' book looks lonely on my bookshelf.

It is quite satisfying to see invariants like Maxwell's equations hold.  And happily, not a single mention of AI in the talk. I did hear a funny quote, though, from another senior engineer during a dinner hosted by some executive recruiters at from local tech company when I asked him for his hot takes on AI. He told me that when presented with what he believes is AI generated content, such as a specification, he updated his former reply of 'TL;DR' now with 'AI;DR.'  Nice. 

As always, history doesn't repeat itself but it does rhyme. During my time at the Cornell high-energy lab I recall work on traveling wave tubes, ion beams, etc and the mention of applicability SDI / 'Star Wars' https://en.wikipedia.org/wiki/Strategic_Defense_Initiative as a use-case; I don't recall if they had funding for that work or not as I was a lowly undergrad tinkering away in the lab.  And the rhyming continues https://en.wikipedia.org/wiki/Golden_Dome_(missile_defense_system. 

So back to the UW talk by the Helion scientist.  Ironically here's an email I received 30 minutes before the lecture

So from high-end steak dinner with one tech monster company to a startup solicitation in the space of a day, quite the interesting job scene.

On the theme of job markets (and I promise I'll tie this back to the initial them of electromagnetics), they definitely seem to go in cycles, too. Since I graduated a semester early from my undergrad I missed a lot of the on-campus interviewing and ended up returning to Texas without an offer in hand in January 1992. Given that environment I considered going back to grad school at the time and debated building upon my Bachelor's in electrical engineers by diving deeper into statistical signal processing at Texas A&M in College Station, TX or electromagnetics at Texas Tech in Lubbock, TX. 

I still remember visiting Tech campus and talking to my prospective advisor. He was a tall man of Norwegian descent who had fully acculturated to Texas. I recall how he referred to Lubbock as "the land of 2π steradians" as a clever, nerdy way to describe Lubbock's exceptionally flat landscape.

I didn't do the campus visit for A&M, though. Luckily Tom Parks, of https://en.wikipedia.org/wiki/Parks%E2%80%93McClellan_filter_design_algorithm fame, was my Cornell advisor so I was accepted without much concern.

Why electromagnetics? 

I think I caught the bug for the topic while doing my internship at Texaco in the summer of 1991. During that time I was asked to do some measurements on the efficacy of a capacitive sensor for different oil/water mixtures. I think they called them 'water cut' sensors which had commercial value since when oil flows through your pipeline it's important to know how much is crude versus water. Doing the experiments was fun but as always I got the itch to understand the device from first principles. Since it was a first party sensor, what are the options to change the electrode geometry, what are the expected results, etc. As such, I broke out my Turbo Pascal and wrote 1800 lines of a device simulation. I wasn't aware of the latest techniques in writing de novo simulations since I'd used canned tools like Superfish mentioned earlier, so I visited University of Houston and read different books and articles. 

https://github.com/vincentjzimmer/Documents/blob/master/device-simulation-august-1991.pdf

BTW at the bottom of page 1 I mention the technique 'successive over relaxation.' When I was asked to make a technical presentation for my first full-time job post-undergrad at Daniel Industries I discussed this work. One of the interviewers, a British gentleman named Graham(?) if I recall with a crew cut, replied 'that sounds like what I do on vacation.'

Back to our regularly-scheduled programming.

Now that I was onto the problem statement of using physical phenomena for building sensors, during this same 1991 internship at Texaco I proposed and prototyped a fiber-optic technique for measuring properties of fluids. I always enjoyed the software side more than the hardware, though, and I still recall the analog engineer at Texaco looking at my breadboarded op amp circuitry which helped drive my experiments and asking 'where is the hardware'?

As part of my house-cleaning of late, you'll see old items I've mentioned like NSA job letter, Cornell engineer magazine, etc. in earlier blog postings. The above report and below post-internship correspondence also appeared as I loaded bags for the Sammamish shredding event. After the internship, Texaco prepared a patent application naming me as the primary inventor, although I have not located a corresponding published application or issued patent.

I did find part of that post-internship patent application draft

and corresponding office action.

And it looks like attorney is still around, too

https://referlex.com/attorney/50fd243c-6ae1-45c4-ade0-4a7f654e6dfd although Texaco was acquired by Chevron quite some time ago. 

And there's my "Vince" tell in the "Dear Vince" above office action correspondence. I always say that when someone calls me 'Vince' they really don't know me. I'm entirely too high strung to go by such a happy-go-lucky name as 'Vince.' Even as a child my mother told me I'd correct adults who called my 'Vince' by saying 'No, my name is Vincent.' 

And little did I know in 1992 that I would see a raft of office actions across 100's of patents 1997+. You have to have quite a thick skin to wade through those objections without taking it personally. I learned a trick at Intel, though. When lawyers would ask me to help address an office action I'd reply "I'd love to but doesn't my employment contract preclude me from reading other company patents for fear of treble damages in case discovery proves I knew about them" or somesuch armchair lawyering I found myself embarrassingly doing back in the day.

OK. A third Saturday in a row of blogging?  What gives? Maybe some nostalgia from the earlier 90's spurred by finding old papers https://vzimmer.blogspot.com/2025/07/early-career-aspirations.html https://vzimmer.blogspot.com/2026/06/wind-energy-and-long-arc-cornell.html during the house clean-up? A pause in the storm of project work? Who knows other than time to get back to work.

Pushing the frontier of knowledge

I was answering some questions about secure boot recently, and 'Building Secure Firmware' https://link.springer.com/book/10.1007/978-1-4842-6106-4 was mentioned. 

 

While visiting the book site I was curious about who was citing it these days https://link.altmetric.com/details/93414671/citations. 

This list is always interesting to compare against the big G's citations https://scholar.google.com/scholar?oi=bibs&hl=en&cites=16997507852059049037. Not surprisingly Scholar omits the above citation - perhaps the big G's Skynet is deprioritizing jobs on Scholar and Patents in lieu of training and serving the latest Gemini? 

Regarding the Apress citations, I was intrigued by the 2027 confidential computing (CC) book chapter mention. After clicking in I was happily surprised (well, maybe not so 'surprised' given the energy and intelligence of the author) to find https://www.sciencedirect.com/book/monograph/9780443540677/confidential-computing

by Jiewen Yao. Although several years have passed since I've had contact with Jiewen, he was a collaborator on the Secure Firmware book and many other projects, patents, presentations and papers back in the day for the EDKII and security space at Intel. In fact upon retiring from Intel I asked him to take up my chair of the UEFI Security Subteam and seat on the Trusted Computing Group Technical Committee (as Intel's rep). 

When he dove into confidential computing many moons ago, I joked to myself that he 'graduated' from UEFI middle school into confidential computing college, whereas I stayed back in the UEFI classroom.

Speaking of graduation, I'm honored to be among the members of the network he mentions (one of the thirty or so Intel souls cited), too https://www.sciencedirect.com/science/chapter/monograph/pii/B9780443540677050014

Although I dabbled in various uses of SGX for firmware, the precursor of the virtualization-based TDX for CC, I spent less energy on TDX while at Intel. One bridge from TDX to host firmware, though, is https://patents.google.com/patent/US20250258963A1/en 

Interesting that the above is classified under 'Secure Boot' by the USPTO. Apparently I have a few under that category https://patents.google.com/?q=(G06F21%2f575)&inventor=vincent+zimmer&oq=(G06F21%2f575)+vincent+zimmer  I'm curious as to how they manager their taxonomies at the USPTO.

As evidence of those two arcs of CC versus UEFI, Jiewen continues to maintain his firmware work as he has also moved into a solo book on confidential computing, I would imagine. On my side, I'm still enrapt by host firmware, including UEFI, with a steady diet of various UEFI implementations and now more reaches into the OS. I guess that a quarter century in an area builds some stickiness (1998 IBI, 1992 EFI1.02?). 

A fortiori, I still want to fulfill my drive to add more formal rigor to the host firmware domain. A scan of this blog and some of my earlier talks and books will make that ambition no surprise. One example of my post-Intel work in this vein includes a paper https://zenodo.org/records/22834103 I'll present in late October https://www.ieee-cars.org/program/papers?q=zimmer

This paper's definitely incomparable to a full-up book, weighing in at 8 versus 400 pp., but it is some small signal of how I'm still trying to move the needle in my perhaps Quixotic quest to formalize UEFI. I started here with some formalization of the circa 2008/9 Firmware Management Protocol https://www.intel.com/content/dam/doc/guide/uefi-secure-firmware-lockdown-idf2009-presentation.pdf and Capsule (from 2006 https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908)

update flows https://uefi.org/specs/UEFI/2.11/Frontmatter/Revision_History.html and open source artifacts https://github.com/tianocore/edk2.

As far as more books on my side, hats off to Jiewen for his accomplishment. From my book publication run of 2006 to 2022, memories of getting hounded by editors for some of those nine texts still gives me the night sweats at times. Writing a book while balancing an intense tech-industry job is like having two jobs concurrently. 

Who knows, though, given the rapid advance of technology it's definitely a target-rich environment I might tap into again? Tech books definitely don't yield any real pecuniary gain but to me they help scale technologies and pass on wisdom learned through hard-fought years of technical investment. I often challenge myself to write a book that I wish I'd had way back when I started in a domain myself.

Well, maybe it's time to close another Saturday entry into my decidedly peripatetic blog. Now back to work.

Reunion cycle

I just received the following post-card in the mail for https://www.cornell.edu/

[front]

[back]

This round of reunions appears to target graduates in years ending in 2's and 7's

I recall that a couple of Anduril executives, Brian Schimpf and Matt Grimm https://www.anduril.com/anduril-leadership, are each Cornell graduates. It turns out that each appear to be 7's. Courtesy of Linkedin, viz., 

with this being their 20th with the 7 suffix. The CU lineage came to my mind after seeing them together in a presentation shortly after receiving this card. 

For this reunion round I'm targeting my 35th graduation anniversary with a 2 suffix (1/1992)

 

A 15 year gap between their graduation and mine which is not quite a generational gap (20-30 years), although it has definitely been a generation of graduates between my cohort in 1992 and the recent class.

This last point of generational gaps come to the fore for me when I bumped into the parody page  https://theonion.com/man-confident-he-wouldve-been-brave-enough-to-send-thumbs-down-emoji-in-cornell-group-chat/

I guess that I have inadvertently been 'brave' since I find myself often giving the thumbs-up emoji in Slack when I want to acknowledge a message. I confess that I had to Google the below explanation after reading the Onion headline above.

Maybe a potential use for personal ambient AI is to provide me a pop-up when I commit these faux pas in the future :)  

Beyond better instant messaging hygiene, it would be interesting to visit the Cornell campus since I haven't been there since 1992. I wonder if my EE haunt of Philips Hall, the proximate Upson Hall for comp sci on the engineering quad, and the hike to White Hall for math (if my memory holds) are still around.

And given the beauty of the region, Ithaca definitely qualifies for the saying https://alumni.cornell.edu/cornellians/ithaca-is-gorges/.  Hopefully Ithaca hasn't gone all Austin, TX, namely tie-die of "Keep Ithaca Weird". I can only absorb so much change in this era of break-neck AI dynamism. 

Another nice thing about Cornell is that my email address vjz1@cornell.edu is a forever address that is also backed by a free Gmail account with storage

Go Big Red.

UW pulled its free Gmail and storage for my email vzimmer@uw.edu, although it still supports forwarding. And now IEEE is separately charging for its Gmail to keep vzimmer@ieee.org alive. Luckily ACM is maintaining its forwarding vincentzimmer@acm.org. This IEEE change coincides with Intel Retiree organization 'retiring' email forwarding, so I'm now losing vincent.zimmer@intelretiree.com too. Oh well.

The transient nature of email accounts reminds me of the ephemeral nature of the internet. I sometimes snap pictures of web sites I cite since as this blog ages the links end up going stale as content ages off the web.

OK.  Enough random editorial for a Saturday.  Back to work.

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?

IPv6 Crosses 50% — Technology Diffusion Takes Longer Than You Think

I noticed the 50% figure on Google's IPv6 stats page https://www.google.com/intl/en/ipv6/statistics.html on 4/16/2026, flagged on Hacker News https://news.ycombinator.com/item?id=47777894. A milestone worth pausing on, even if the headline buries the lead: it took roughly 20 years from IPv6's formal definition (RFC 2460, 1998) to get halfway there.

The culprit is obvious in retrospect — NAT gave IPv4 a decade-long second life and removed any burning platform. Why pay migration cost when carrier-grade NAT works fine?

From a firmware perspective, the story is actually a bright spot. RFC 5970 https://www.rfc-editor.org/rfc/rfc5970.txt 

standardized network boot over IPv6 (DHCPv6/PXE) in 2010, and the firmware stack moved quickly. I was part of the team that implemented dual-stack IPv4/IPv6 network boot support in EDK2 https://github.com/tianocore/edk2 — the open-source UEFI reference firmware — had it certified at the UNH Interoperability Lab https://www.iol.unh.edu/, and codified in the UEFI specification. That code has been fully deployed since the RFC landed and ships today in the host firmware of most PCs, servers, and devices like the NVIDIA Jetson. The iPXE project https://ipxe.org/ is the other prominent host-side implementation and likewise supports RFC 5970. The IPv6 TFTP/PXE boot foundation was then leveraged for HTTP boot, which is the modern evolution now widely used for network-based firmware provisioning.  I journaled bit of this in places like https://github.com/vincentjzimmer/Documents/blob/master/UEFI-Recovery-Options-002-1.pdf, https://www.intel.com/content/dam/www/public/us/en/documents/research/2011-vol15-iss-1-intel-technology-journal.pdf, and https://uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf.

So firmware did its job — standards written through the IETF and UEFI Forum, code certified, silicon shipping, HTTP boot built on top. The 50% adoption story is really about everything above the firmware layer: ISP rollout, enterprise network operations, and the long tail of IPv4 infrastructure that NAT kept alive just long enough to delay the transition by a decade.

That's the part that still surprises me. When the firmware stack is ahead of the network, you know diffusion is the bottleneck, not implementation.

PlanetNix and 490

I've spent the last few months getting more familiar with Nix. Although "Nix" is an informal verb meaning to cancel, reject, or veto a plan or idea, and the term also functions as a noun representing "nothing" (derived from the German nichts), my interaction has been with the software aspect https://nixos.org/. 

As a background, Nix is a powerful, functional package manager and build system designed for reproducible, declarative, and reliable software management. Key aspects of Nix technology include declarative configuration, reproducible builds, atomic upgrades/rollbacks and a pure functional language to define packages and configurations. There is also NixOS, a Linux distribution built on top of the Nix package manager which allows the entire operating system configuration to be declared and managed in a single file. Well ok, maybe three files - configuration.nix, hardware.nix and flake.nix.

One of the best resources for grokking Nix is Dolstra's Phd thesis https://edolstra.github.io/pubs/phd-thesis.pdf.  And in fact Dolstra was a speaker at https://planetnix.com/2025/speakers/ which I attended in Pasadena recently. The conference also featured an insightful talk from Shopify on their Nix usage and a surprisingly large presence of Anthropic folks in the vendor area. Maybe the latter detail explains why Claude Opus is so good at writing and debugging Nix derivations and closures?

Another speaker at PlanetNix was Kelsey Hightower https://en.wikipedia.org/wiki/Kelsey_Hightower who at 45 noted that this was going to be his last conference talk. This was the first time I'd seen Kelsey in person. He opined about AI and its impact on software engineering as did many talks at the conference.  His "I'm done with conference speaking at 45" definitely made me pause about the passage of time. 

Speaking of the passage of time, fast forward a week or so from PlanetNix and today I noticed that the USPTO just issued US Patent #12,578,956. My issue rate has definitely dwindled and this one marks my 490th issued US patent. I was curiously hoping to hit 500 as a lifetime goal but the dozen or so applications left in suspended or office action status don't augur well for that milestone. To get an appreciation of the span of time here, my first issued patent was October 1999 https://patents.google.com/patent/US5940587A/en, or a quarter of a century ago...

Regarding the specific patent that landed today

I enjoyed my collaboration with these Intel colleagues working in this problem domain.  The IP represents work done on system updates, an area that has been alternately touched upon other places https://raw.githubusercontent.com/tianocore-docs/Docs/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf, https://link.springer.com/book/10.1007/978-1-4842-6106-4, https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure, https://github.com/vincentjzimmer/Documents/blob/master/SF11_EFIS002_100.pdf, ....

Regarding the theme of the passage of time, of my co-inventors from 2021 when this was filed I believe they are now distributed as follows: Niv - Intel, Prashant - Microsoft, Subrata - Google, Ofir - Google, Baiju - retired, Yazan - Nvidia,  Kumar - Google, Vincent - Anduril. So it looks like Google has the highest density here at 38% as these five years have progressed.

Speaking of progressing, time to progress to a non-blogging state and close this item. Good night.