Re: [RFC PATCH] fs/splice: allow for a way to block splice() with read-only files

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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