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

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

Date:   Tue, 12 Jan 2021 19:35:48 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     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,
        tariqt@...dia.com, Eric Dumazet <edumazet@...gle.com>,
        Cong Wang <xiyou.wangcong@...il.com>, ap420073@...il.com,
        Jiri Pirko <jiri@...lanox.com>, borisp@...dia.com
Subject: Re: [net] net: feature check mandating HW_CSUM is wrong

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.