Firmware bugs

I mentioned how history doesn't repeat itself but it does rhyme in a few recent posts.  Here's to more rhyming this week, with the PXE failure bug https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/. I saw at lot of alarmist behavior. To me it's simply a new generation of folks who realize that firmware is buggy.  Or the natural progression of the tech wherein the more something is used the more defects will surface. In the early days of UEFI you could breath hard against the stack and it would tip over, such as it's vulnerability to things like https://en.wikipedia.org/wiki/Ping_of_death.

This type of commentary on firmware reminds me of my old dichotomy of this domain as 'value add' versus 'value neutral.' I had originally thought that the rich EFI and UEFI capabilities would allow for adding value to the platform, but I successively realized that firmware is just basic utility infrastructure that provides inherent value when it 'just works.' It vectors into negative value territory when it is expensive to develop, boots slowly, has security issues that need remediation, or is complex to configure.  So the goal of the mission always entails moving the needle out of the value territory.

And in lieu of correct by construction, the next best thing to do is allow for servicing/updating at scale. In the early 2000's firmware updates were rarely cryptographically signed, so the first mission was to scale signed updates https://csrc.nist.gov/pubs/sp/800/147/final. After that the mission was to make updates reliable https://csrc.nist.gov/pubs/sp/800/193/final. And finally the challenge was to enable and evangelize the capability to the ecosystem https://embeddedcomputing.com/technology/security/software-security/understanding-uefi-firmware-update-and-its-vital-role-in-keeping-computing-systems-secure. It was a long road to travel.

Other sentiments on this space include when I see one-off alarmist stories like this, I think of the attacker versus defender dichotomy. I'm more a fan of sentiments like Dino's:

"I don't think security researchers identifying vulnerabilities one-by-one will provide as much value as security *engineers* who can proactively prevent every vulnerability alert from being a SEV-0 or turning into a security incident." 

https://x.com/dinodaizovi/status/2115943958635597824

He has continued to be a voice a reason. I still fondly recall our DAC2015 panel https://dl.acm.org/action/showFmPdf?doi=10.1145/2744769

This panel discussion included the all important dimension of platform economics that I didn't treat in the firmware update memory-lane narrative above.