Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95DC8C636D6 for ; Mon, 20 Feb 2023 04:55:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229740AbjBTEzI (ORCPT ); Sun, 19 Feb 2023 23:55:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjBTEzG (ORCPT ); Sun, 19 Feb 2023 23:55:06 -0500 Received: from 167-179-156-38.a7b39c.syd.nbn.aussiebb.net (167-179-156-38.a7b39c.syd.nbn.aussiebb.net [167.179.156.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BF979753; Sun, 19 Feb 2023 20:55:05 -0800 (PST) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1pTyCK-00DEmI-ML; Mon, 20 Feb 2023 12:54:45 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Mon, 20 Feb 2023 12:54:44 +0800 Date: Mon, 20 Feb 2023 12:54:44 +0800 From: Herbert Xu To: Andy Lutomirski Cc: Dave Chinner , torvalds@linux-foundation.org, metze@samba.org, axboe@kernel.dk, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, samba-technical@lists.samba.org Subject: Re: copy on write for splice() from file to pipe? Message-ID: References: <20230210061953.GC2825702@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt