linux-kernel - Re: copy on write for splice() from file 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] [day] [month] [year] [list]

Date:   Mon, 20 Feb 2023 12:54:44 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Dave Chinner <david@...morbit.com>, torvalds@...ux-foundation.org,
        metze@...ba.org, axboe@...nel.dk, linux-fsdevel@...r.kernel.org,
        linux-api@...r.kernel.org, io-uring@...r.kernel.org,
        linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
        samba-technical@...ts.samba.org
Subject: Re: copy on write for splice() from file to pipe?

On Fri, Feb 17, 2023 at 03:13:14PM -0800, Andy Lutomirski wrote:
>
> I can certainly imagine TLS or similar protocols breaking if data
> changes if the implementation is too clever and retransmission
> happens.  Suppose 2000 bytes are sent via splice using in-kernel TLS,
> and it goes out on the wire as two TCP segments.  The first segment is
> dropped but the second is received.  The kernel resends the first
> segment using different data.  This really ought to cause an integrity
> check at the far end to fail.

The TLS layer is completely separate from TCP so it's like any
normal TCP user from user-space.  IOW the encrypted data will be
held by TCP until acknowledged so during retransmission it will
simply resend the previously encrypted data rather than encrypting
the same data twice.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt