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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Nov 2020 22:48:22 +0530
From:   rohit maheshwari <rohitm@...lsio.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     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 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?