netdev - Re: [PATCH net] net/tls: Fix kernel panic when socket is in TLS ULP

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: <20201110082832.4ef61eff@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 10 Nov 2020 08:28:32 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vinay Kumar Yadav <vinay.yadav@...lsio.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, borisp@...dia.com,
        secdev@...lsio.com
Subject: Re: [PATCH net] net/tls: Fix kernel panic when socket is in TLS ULP

On Tue, 10 Nov 2020 10:37:11 +0530 Vinay Kumar Yadav wrote:
> It is not incompatible. It fits in k.org tls infrastructure (TLS-TOE 
> mode). For the current issue we have proposed a fix. What is the issue 
> with proposed fix, can you elaborate and we will address that?

Your lack of understanding of how netdev offloads are supposed to work
is concerning. Application is not supposed to see any difference
between offloaded and non-offloaded modes of operation.

Your offload was accepted based on the assumption that it works like
the software kernel TLS mode. Nobody had the time to look at your
thousands lines of driver code at the time.

Now you're telling us that the uAPI for the offload is completely
different - it only works on listening sockets while software tls 
only works on established sockets. Ergo there is no software fallback
for your offload.

Furthermore the severity of the bugs you just started to fix now, after
the code has been in the kernel for over a year suggests there are no
serious users and we can just remove this code.