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

[Pedro Falcato <pfalcato@suse.de>]

Hello,

Apologies for the delay (laziness^Wconferences, travel and the sort),

On Fri, May 22, 2026 at 03:11:11PM +0200, Christian Brauner wrote:
> On Tue, May 19, 2026 at 01:56:42PM +0200, Mateusz Guzik wrote:
> > On Tue, May 19, 2026 at 12:59 PM Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > On 2026-05-19 12:51 +0200, Mateusz Guzik wrote:
> > > > How about denial of splice usage or degradation to copy are still on
> > > > the table, but based on a different criterion: whether code involved
> > > > is "known good" for lack of a better description. iow the kernel would
> > > > maintain a whitelist of "safe" cases. Random-ass AF_NOBODYEVERHEARDOF
> > > > does not make the cut.
> > >
> > > I had thought about that to but I felt a bit iffy about it. You could
> > > envision an FOP_* flag for this:
> > >
> > >   /* Module may use splice-like apis */
> > >   #define FOP_MAY_SPLICE          ((__force fop_flags_t)(1 << 8))

FWIW, I don't think this works. Sockets expose the same file_operations struct
for every socket. So while it could work for other dodgy fd's around the kernel, I
would hope there isn't many of them... (or at least many of them using splice,
etc).

> > >
> > > But that doesn't address how fundamentally broken vmsplice() for example
> > > really is and that probably no one should get to use it in its current
> > > form.

Right.

> > 
> > I never looked into the area on Linux, I am willing to take claims of
> > breakage on face value.
> > 
> > In this context I'm saying the functionality is used in the real world
> > for performance reasons and just whacking imo does not cut it.

Which is why I wanted to introduce the (admittedly, rather adhoc) approach
of limiting it to files that could already be written to. So hopefully it
could actually be deployed. I'm afraid many users out there will not deploy
a "go slower, safer" flag.

> > 
> > >
> > > > Common-case usage would have to be audited of course, but this sounds
> > > > rather actionable and would provide hardening without much friction.
> > >
> > > And that's the usual problem where rando module will just raise the
> > > flag. Maybe that's fine and we will keep up.
> > >
> > 
> > If this is a genuine worry the whitelist can still be introduced and
> > managed by one person (Linus?) very easily. The implementation is only
> > mildly cumbersome to get going and trivial to spread afterwards.
> > 
> > You could have something like this:
> > struct file_operations funky_ops = {
> > ....
> > };
> > VFS_FILE_OPS_REGISTER(funky_ops);
> 
> Unless someone is going to do that work a sysctl to force degrade all
> the APIs into copies should be ok.

Ok. It seems that the general consensus is KISS and just degrade everything
with the sysctl? I can do that for v2.

-- 
Pedro