I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?

I've been thinking similarly, that we're quickly going to want to start minimising dependencies and code size in the programs we make to try to reduce attack surface area.

> to very minimal and hyperspecific firmware (300 lines of assembly)

So, just normal BIOS boot?

Yea I really like this idea.

We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.

When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.

Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.

>You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable.

So the solutions need to be structural.

e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.

Everything running under seL4 benefits from the guarantees seL4 provides.