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] [day] [month] [year] [list]

Message-ID: <4fdc9dd2-fbdf-2d5e-9836-74cb8dd3062c@chelsio.com>
Date:   Wed, 11 Nov 2020 01:19:24 +0530
From:   Vinay Kumar Yadav <vinay.yadav@...lsio.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 11/10/2020 9:58 PM, Jakub Kicinski wrote:
> 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.
> 
For application point of view there won't be any difference.
kernel tls in tcp offload mode works exactly similar to software
kTLS.

> 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.
>
We can consider adding the capability to working with established 
sockets.The TOE has not needed that capability to date since it can 
establish the socket itself, but it makes sense to provide uniformity 
with the kTLS approach so we will look into that.  For now, as you 
suggested replacing stack listen with toe listen makes more sense.

> 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.
> 
It’s been a slow process but with the new team it is picking up speed
and the quality of the code will continue to get better.