netdev - Re: [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe

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: <CAHk-=whYWEUU69nY6k4j1_EQnQDNPy4TqAMvpf1UA111UDdmYg@mail.gmail.com>
Date: Thu, 29 Jun 2023 11:19:36 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matt Whitlock <kernel@...twhitlock.name>
Cc: David Howells <dhowells@...hat.com>, netdev@...r.kernel.org, 
	Matthew Wilcox <willy@...radead.org>, Dave Chinner <david@...morbit.com>, Jens Axboe <axboe@...nel.dk>, 
	linux-fsdevel@...ck.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe

On Thu, 29 Jun 2023 at 11:05, Matt Whitlock <kernel@...twhitlock.name> wrote:
>
> I don't know why SPLICE_F_MOVE is being ignored in this thread. Sure, maybe
> the way it has historically been implemented was only relevant when the
> input FD is a pipe, but that's not what the man page implies. You have the
> opportunity to make it actually do what it says on the tin.

First off, when documentation and reality disagree, it's the
documentation that is garbage.

Secondly, your point is literally moot, from what I can tell:

       SPLICE_F_MOVE
              Unused for vmsplice(); see splice(2).

that's the doc I see right now for "man vmsplice".

There's no "implies" there. There's an actual big honking clear
statement at the top of the man-page saying that what you claim is
simply not even remotely true.

Also, the reason SPLICE_F_MOVE is unused for vmsplice() is that
actually trying to move pages would involve having to *remove* them
from the VM source. And the TLB invalidation involved with that is
literally more expensive than the memory copy would be.

So no. SPLICE_F_MOVE isn't the answer.

Now, we also have SPLICE_F_GIFT. That's actually a more extreme case
of "not only should you taekm this page, you can actually try to
re-use the end result for your own nefarious purposes".

Now, I would actually not disagree with removing that part. It's
scary. But I think we don't really have any users (ok, fuse and some
random console driver?)

            Linus