On Tue, May 19, 2026 at 01:56:42PM +0200, Mateusz Guzik wrote: > On Tue, May 19, 2026 at 12:59 PM Christian Brauner <[email protected]> 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)) > > > > 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. > > 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. > > > > > > 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.
