From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net] tls: fix currently broken MSG_PEEK behavior Date: Mon, 17 Sep 2018 08:04:57 -0700 (PDT) Message-ID: <20180917.080457.483898191006335332.davem@davemloft.net> References: <20180914210055.2558-1-daniel@iogearbox.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: davejwatson@fb.com, doronrk@fb.com, alexei.starovoitov@gmail.com, john.fastabend@gmail.com, netdev@vger.kernel.org To: daniel@iogearbox.net Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:45886 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728394AbeIQUcm (ORCPT ); Mon, 17 Sep 2018 16:32:42 -0400 In-Reply-To: <20180914210055.2558-1-daniel@iogearbox.net> Sender: netdev-owner@vger.kernel.org List-ID: From: Daniel Borkmann Date: Fri, 14 Sep 2018 23:00:55 +0200 > In kTLS MSG_PEEK behavior is currently failing, strace example: ... > As can be seen from strace, there are two TLS records sent, > i) 'test_read_peek' and ii) '_mult_recs\0' where we end up > peeking 'test_read_peektest_read_peektest'. This is clearly > wrong, and what happens is that given peek cannot call into > tls_sw_advance_skb() to unpause strparser and proceed with > the next skb, we end up looping over the current one, copying > the 'test_read_peek' over and over into the user provided > buffer. > > Here, we can only peek into the currently held skb (current, > full TLS record) as otherwise we would end up having to hold > all the original skb(s) (depending on the peek depth) in a > separate queue when unpausing strparser to process next > records, minimally intrusive is to return only up to the > current record's size (which likely was what c46234ebb4d1 > ("tls: RX path for ktls") originally intended as well). Thus, > after patch we properly peek the first record: ... > Fixes: c46234ebb4d1 ("tls: RX path for ktls") > Signed-off-by: Daniel Borkmann Applied and queued up for -stable.