netdev - Re: [net-next 10/11] net/mlx5e: kTLS, Add kTLS RX resync support

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]

Message-ID: <20200603195659.4d6a1060@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 3 Jun 2020 19:56:59 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tariq Toukan <tariqt@...lanox.com>
Cc:     Boris Pismenny <borisp@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-next 10/11] net/mlx5e: kTLS, Add kTLS RX resync support

On Wed, 3 Jun 2020 10:02:33 +0300 Tariq Toukan wrote:
> > IIUC the HW asks for a resync at the first record after a specific seq
> > (the record header is in the frame that carried the OOO marking, right?)
> > 
> > Can we make the core understand those semantics and avoid trying to
> > resync at the wrong record?
> 
> HW asks for a resync when it is in tracking mode and identifies the 
> magic, so it calculates the expected seq of next record.
> This seq is not part of the completion (for now, this is a planned 
> enhancement), so the device driver posts a request to the device to get 
> the seq, and then the driver hopefully approve it (by another post to 
> the HW) after comparing it to the stack sw seq.
> 
> As long as the device driver does not know the HW expected seq, it 
> cannot provide a seq to the stack. So force resync is used.

Right, what I was trying to say is that the HW will likely latch on the
first magic in the TCP segment, so maybe the driver and the core can
reasonably expect that. Driver can tell the core to provide first
record after TCP seq_no X. Otherwise if the TCP socket is backed up
driver may get a very old record.

Just clarifying what I was trying to say, not sure how that fits your
device.

> We can think of an optimization here, it is doable.