netdev - Re: Avoid unprivileged splice(file->)/(->socket) pipe exclusion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d4ocnyfwlwqfdthubds6yshbn2xk67rsjh32glhkjtzcvq4x6k@tarta.nabijaczleweli.xyz>
Date: Mon, 25 Dec 2023 22:50:17 +0100
From: 
	Ahelenia Ziemiańska <nabijaczleweli@...ijaczleweli.xyz>
To: Askar Safin <safinaskar@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-man <linux-man@...r.kernel.org>, linux-s390@...r.kernel.org, linux-serial@...r.kernel.org, 
	netdev@...r.kernel.org, virtualization@...ts.linux.dev
Subject: Re: Avoid unprivileged splice(file->)/(->socket) pipe exclusion

On Tue, Dec 26, 2023 at 12:34:44AM +0300, Askar Safin wrote:
> In https://lore.kernel.org/lkml/CAHk-=wgG_2cmHgZwKjydi7=iimyHyN8aessnbM9XQ9ufbaUz9g@mail.gmail.com/
> Linus said:
> > I have grown to pretty much hate
> > splice() over the years, just because it's been a constant source of
> > sorrow in so many ways.
> 
> > It's just that it was never as lovely and as useful as it promised to
> > be. So I'd actually be more than happy to just say "let's decommission
> > splice entirely, just keeping the interfaces alive for backwards
> > compatibility"
> So probably we should do this as Linus suggested? I. e. fully remove
> splice by replacing it with trivial read-write?
I am doing just like he suggested downthread of my original report, in
  https://lore.kernel.org/linux-fsdevel/CAHk-=wimmqG_wvSRtMiKPeGGDL816n65u=Mq2+H3-=uM2U6FmA@mail.gmail.com/
> But it is possible that we need to just bite the bullet and say
> "copy_splice_read() needs to use a non-blocking kiocb for the IO".

I see it post-dates the thing you cited,
which naturally makes it more valid,
and it directly references this particular issue,
instead of an annoying data corruption one.

This whole series effectively amounts to three patches
(delete splice_* form ttys,
 make IPC splice_read  nonblocking when lock is held,
 make IPC splice_write nonblocking when lock is held)
just the latter two to thirty implementations of the same funxion.

This is hardly reason to kill an interface that doubles the performance
of a very common operation IMO.

Honestly, no-one would probably run into this in another decade
if just the splice_* deletion from ttys was implemented;
this is just thoroughness to a fault since you can spin this as a
security issue, really.

Best,

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)