netdev - Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <0d10033a-7ea1-48e3-806b-f74000045915@mattwhitlock.name>
Date: Wed, 19 Jul 2023 19:41:07 -0400
From: Matt Whitlock <kernel@...twhitlock.name>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Matthew Wilcox <willy@...radead.org>,
 Miklos Szeredi <miklos@...redi.hu>,
 David Howells <dhowells@...hat.com>,
 <netdev@...r.kernel.org>,
 Dave Chinner <david@...morbit.com>,
 Jens Axboe <axboe@...nel.dk>,
 <linux-fsdevel@...ck.org>,
 <linux-mm@...ck.org>,
 <linux-kernel@...r.kernel.org>,
 Christoph Hellwig <hch@....de>,
 <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns

On Wednesday, 19 July 2023 19:20:32 EDT, Linus Torvalds wrote:
>> On Wednesday, 19 July 2023 16:16:07 EDT, Linus Torvalds wrote:
>>> The *ONLY* reason for splice() existing is for zero-copy.
>> 
>> The very first sentence of splice(2) reads: "splice() moves data between
>> two file descriptors without copying between kernel address space and user
>> address space." Thus, it is not unreasonable to believe that the point of
>> splice is to avoid copying between user-space and kernel-space.
>
> I'm not at all opposed to clarifying the documentation.

Then that is my request. This entire complaint/discussion/argument would 
have been avoided if splice(2) had contained a sentence like this one from 
sendfile(2):

"If out_fd refers to a socket or pipe with zero-copy support, callers must 
ensure the transferred portions of the file referred to by in_fd remain 
unmodified until the reader on the other end of out_fd has consumed the 
transferred data."

That is a clear warning of the perils of the implementation under the hood, 
and it could/should be copied, more or less verbatim, to splice(2).