netdev - Re: [net] net: feature check mandating HW

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, 13 Jan 2021 19:07:20 +0200
From:   Tariq Toukan <ttoukan.linux@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        rohit maheshwari <rohitm@...lsio.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>, secdev@...lsio.com,
        Alexei Starovoitov <ast@...nel.org>,
        Björn Töpel <bjorn.topel@...el.com>,
        Daniel Borkmann <daniel@...earbox.net>, andriin@...com,
        Eric Dumazet <edumazet@...gle.com>,
        Cong Wang <xiyou.wangcong@...il.com>, ap420073@...il.com,
        Jiri Pirko <jiri@...lanox.com>, borisp@...dia.com,
        Tariq Toukan <ttoukan.linux@...il.com>,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [net] net: feature check mandating HW_CSUM is wrong



On 1/13/2021 5:35 AM, Alexander Duyck wrote:
> On Tue, Jan 12, 2021 at 6:43 PM rohit maheshwari <rohitm@...lsio.com> wrote:
>>
>>
>> On 07/01/21 12:47 AM, Jakub Kicinski wrote:
>>> On Wed,  6 Jan 2021 23:23:27 +0530 Rohit Maheshwari wrote:
>>>> Mandating NETIF_F_HW_CSUM to enable TLS offload feature is wrong.
>>>> And it broke tls offload feature for the drivers, which are still
>>>> using NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM. We should use
>>>> NETIF_F_CSUM_MASK instead.
>>>>
>>>> Fixes: ae0b04b238e2 ("net: Disable NETIF_F_HW_TLS_TX when HW_CSUM is disabled")
>>>> Signed-off-by: Rohit Maheshwari <rohitm@...lsio.com>
>>> Please use Tariq's suggestion.
>> HW_TLS_TX feature is for both IPv4/v6. And If one device is limited to
>> support only IPv4 checksum offload, TLS offload should be allowed for
>> that too. So I think putting a check of CSUM_MASK is enough.
> 
> The issue is that there is no good software fallback if the packet
> arrives at the NIC and it cannot handle the IPv6 TLS offload.
> 
> The problem with the earlier patch you had is that it was just
> dropping frames if you couldn't handle the offload and "hoping" the
> other end would catch it. That isn't a good practice for any offload.
> If you have it enabled you have to have a software fallback and in
> this case it sounds like you don't have that.
> 
> In order to do that you would have to alter the fast path to have to
> check if the device is capable per packet which is really an
> undesirable setup as it would add considerable overhead and is open to
> race conditions.
> 

+1

Are there really such modern devices with missing IPv6 csum 
capabilities, or it's just a missing SW implementation in the device driver?

IMO, it sounds reasonable for this modern TLS device offload to asks for 
a basic requirement such as IPv6 csum offload capability, to save the 
overhead.