Two things landed close together that I think belong next to each other.
The first is a UEFI firmware vulnerability allowing code execution, affecting a large number of server platforms. The second is a post from Tinfoil titled Less Is More, describing replacing roughly a million lines of firmware with about three hundred lines of assembly for their specific use case.
Read together they make an argument about attack surface that is easy to agree with and genuinely hard to act on.
Why firmware is such a good place to hide
Firmware sits below the operating system, runs before any of your security tooling exists, persists across reinstalls, and is written in C by vendors under schedule pressure with limited public scrutiny. It is also enormous. Modern UEFI implementations are operating systems in their own right, with network stacks, filesystem drivers, and graphics support, all running at the highest privilege level the machine has.
You inherit every line of it. You did not choose it, you usually cannot read it, and in practice you often cannot patch it quickly because the update path runs through a hardware vendor rather than through you.
That is what makes the three hundred line version interesting. It is not primarily a performance claim. It is a claim about how much code you are required to trust.
The part that is actually hard
The obvious objection is that the comparison is unfair, and it is. The million lines do things: they boot arbitrary operating systems on arbitrary hardware, handle decades of accumulated platform quirks, support every peripheral anyone has ever shipped. The three hundred lines boot one known configuration.
But I think that is the point rather than a rebuttal. Generality is the thing that costs you. A general-purpose firmware has to be ready for hardware it will never actually meet, and you pay for that readiness in attack surface on every machine you own.
If you control the hardware configuration, which cloud operators and appliance vendors increasingly do, the generality is pure cost. The argument is not “firmware should be small”, it is “firmware should be as general as your deployment actually requires, and no more.”
The post also credits LLMs with making this practical, on the grounds that writing small bespoke low-level software got cheaper. I am mildly sceptical of that framing. The hard part of replacing firmware was never typing the assembly. It was knowing which of the million lines you were allowed to drop, and that is exactly the judgement that does not come from a model.
The uncomfortable conclusion
Most of us are not going to rewrite our boot path. The realistic takeaway is narrower and less satisfying: the size of your trusted computing base is a number, you almost certainly do not know what yours is, and almost nobody treats it as something to be managed down.
Every dependency, every vendor blob, every convenience layer added because it was easier than the alternative is a line in that total. The UEFI flaw is a reminder that the bill arrives for code you never wrote and cannot see.
Sources: Less Is More, via TLDR.