netdev - Re: [PATCH v24 00/20] nvme-tcp receive offloads

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 8 Apr 2024 01:21:31 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: Jakub Kicinski <kuba@...nel.org>, Aurelien Aptel <aaptel@...dia.com>
Cc: linux-nvme@...ts.infradead.org, netdev@...r.kernel.org, hch@....de,
 kbusch@...nel.org, axboe@...com, chaitanyak@...dia.com, davem@...emloft.net,
 aurelien.aptel@...il.com, smalin@...dia.com, malin1024@...il.com,
 ogerlitz@...dia.com, yorayz@...dia.com, borisp@...dia.com,
 galshalom@...dia.com, mgurtovoy@...dia.com, edumazet@...gle.com
Subject: Re: [PATCH v24 00/20] nvme-tcp receive offloads



On 06/04/2024 8:45, Jakub Kicinski wrote:
> Doesn't apply, again, unfortunately.
>
> On Thu,  4 Apr 2024 12:36:57 +0000 Aurelien Aptel wrote:
>> Testing
>> =======
>> This series was tested on ConnectX-7 HW using various configurations
>> of IO sizes, queue depths, MTUs, and with both the SPDK and kernel NVMe-TCP
>> targets.
> About testing, what do you have in terms of a testing setup?
> As you said this is similar to the TLS offload:
>
>> Note:
>> These offloads are similar in nature to the packet-based NIC TLS offloads,
>> which are already upstream (see net/tls/tls_device.c).
>> You can read more about TLS offload here:
>> https://www.kernel.org/doc/html/latest/networking/tls-offload.html
> and our experience trying to maintain and extend the very much used SW
> kernel TLS implementation in presence of the device offload is mixed :(
> We can't test it, we break it, get CVEs for it :( In all fairness

Especially when nvme-tcp can also run on tls, but that is incompatible with
this offload at the moment (I've told the nvidia folks that I do not expect
this incompatibility to be permanent).

> the inline offload is probably not as bad as the crypto accelerator
> path, but still it breaks. So assuming that this gets all the necessary
> acks can we expect you to plug some testing into the netdev CI so that
> we see whether any incoming change is breaking this offload?

Agree, also given that there is an effort to extend blktests to run on
real controllers, perhaps we should add a few tests there as well?