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:   Fri, 15 Jan 2021 11:08:34 +0530
From:   rohit maheshwari <rohitm@...lsio.com>
To:     Tariq Toukan <ttoukan.linux@...il.com>,
        Alexander Duyck <alexander.duyck@...il.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 <tariqt@...dia.com>
Subject: Re: [net] net: feature check mandating HW_CSUM is wrong


On 13/01/21 10:37 PM, Tariq Toukan wrote:
>
>
> 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.
>
I agree with you, all modern devices support V6 csum, but still if we think
logically, we can't limit TLS offload to work only if both IPV4_CSUM  and
IPV6_CSUM are configured/supported. If there is no dependency of IPV6
in running TLS offload with IPv4  and vice-versa, then why should there
be any restriction as such.