On Tue, 2026-05-19 at 12:51 +0200, Mateusz Guzik wrote: [...] > I can't stress enough that mucking around splice (even if worthwhile) > is merely addressing the currently popular attack vector and not the > general problem. > > The general problem is that the kernel is expected to be able to run > with untrusted unprivileged users, while it avoidably exposes a huge > attack surface. Of course there is no way around providing a bunch of > syscalls to users, so *some* danger will always be there and one has > to expect that even core code has bugs which will be discovered by > LLMs in the coming months. Even then, there is tons of code which is > currently being audited by third parties and which has no use in most > setups. Instead it gets autoloaded in response to an exploit wishing > to take advantage of its bugs. > > The huge attack surface was always a problematic position to be in, > but with the advent lf LLMs any unskilled person can drop a 0day and > the position is straight up untenable. In the long run there is no > way around blocking access to code by default, way beyond the current > splice proposal.
Attack surface is a great measure for making lower bound security assertions and proofs. I mean I've used it myself to build a container that was provably more secure than a VM: https://blog.hansenpartnership.com/measuring-the-horizontal-attack-profile-of-nabla-containers/ But the point is it is a lower bound: security is always better than the attack surface measure says. The problem with the measure for something like a kernel is that the kernel's job is to provide services to untrusted users, so amazingly enough a plurality of its code goes to this function making, as you say, the attack surface huge. I'm sure there are low hanging little used interfaces we could remove to lower the attack surface, and perhaps we could voluntarily wall off large areas for "secure" users. However, security has always been a tradeoff for usability (the most secure PC is one that's powered off) so the more you wall off the smaller the pool of actual users becomes. I think we should be spending our time on better interface design. As Kees' security project proves: classes of bug can be eliminated via various techniques (effectively rendering extant defects unexploitable) and we can certainly do a better job of error legs, which seems to be where AI is turning up the majority of the issues. The problem with the above is that while it's easy to measure bug density and correlate it directly to attack surface as lower bound mathematics, it's really hard to measure the reductions in exploitability potential that better API, coding and other security techniques give us. I really believe we've done significant improvements to reduce our exploitability, but I can't (yet) measure it. That makes it easy to claim the sky is falling due to the size of our attack surface, but doing so effectively ignores every exploitability improvement we've made over the years (and thus ignores the hard work and dedication of a large group of individuals). Regards, James
