netdev - Re: [net v4 07/10] ch_ktls: packet handling prior to start marker

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]

Message-ID: <20201104120339.2fa198e9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 4 Nov 2020 12:03:39 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     rohit maheshwari <rohitm@...lsio.com>, netdev@...r.kernel.org,
        davem@...emloft.net, secdev@...lsio.com
Subject: Re: [net v4 07/10] ch_ktls: packet handling prior to start marker

On Wed, 4 Nov 2020 22:48:22 +0530 rohit maheshwari wrote:
> On 04/11/20 2:21 AM, Jakub Kicinski wrote:
> > On Fri, 30 Oct 2020 23:32:22 +0530 Rohit Maheshwari wrote:  
> >> There could be a case where ACK for tls exchanges prior to start
> >> marker is missed out, and by the time tls is offloaded. This pkt
> >> should not be discarded and handled carefully. It could be
> >> plaintext alone or plaintext + finish as well.  
> > By plaintext + finish you mean the start of offload falls in the middle
> > of a TCP skb? That should never happen. We force EOR when we turn on
> > TLS, so you should never see a TCP skb that needs to be half-encrypted.  
> This happens when re-transmission is issued on a high load system.
> First time CCS is and finished message comes to driver one by one.
> Problem is, if ACK is not received for both these packets, while
> sending for re-transmission, stack sends both these together. Now
> the start sequence number will be before the start marker record,
> but it also holds data for encryption. This is handled in this
> patch.
> Are you saying this should not happen?

Maybe Eric could help us out - Rohit says that the TCP stack is
generating skbs which straddle MSG_EOR on re-transmit. Can this 
happen / is it correct?