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]

Date:   Mon, 9 Nov 2020 10:58:51 -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 00:21:13 +0530 Vinay Kumar Yadav wrote:
> On 11/7/2020 1:58 AM, Jakub Kicinski wrote:
> > On Sat, 7 Nov 2020 02:02:42 +0530 Vinay Kumar Yadav wrote:  
> >> On 11/6/2020 12:16 AM, Jakub Kicinski wrote:  
> >>> On Thu, 5 Nov 2020 23:55:15 +0530 Vinay Kumar Yadav wrote:  
> >>>>>>> We should prevent from the socket getting into LISTEN state in the
> >>>>>>> first place. Can we make a copy of proto_ops (like tls_sw_proto_ops)
> >>>>>>> and set listen to sock_no_listen?  
> >>>>>>
> >>>>>> Once tls-toe (TLS_HW_RECORD) is configured on a socket, listen() call
> >>>>>> from user on same socket will create hash at two places.  
> >>>>>
> >>>>> What I'm saying is - disallow listen calls on sockets with tls-toe
> >>>>> installed on them. Is that not possible?
> >>>>>        
> >>>> You mean socket with tls-toe installed shouldn't be listening at other
> >>>> than adapter? basically avoid ctx->sk_proto->hash(sk) call.  
> >>>
> >>> No, replace the listen callback, like I said. Why are you talking about
> >>> hash???
> >>> As per my understanding we can't avoid socket listen.  
> >> Not sure how replacing listen callback solve the issue,
> >> can you please elaborate ?  
> > 
> > TLS sockets are not supposed to get into listen state. IIUC the problem
> > is that the user is able to set TLS TOE on a socket which then starts
> > to listen and the state gets cloned improperly.
> 
> TLS-TOE can go to listen mode, removing listen is not an option and
> TLS-TOE support only server mode so if we remove listen then we will not 
> have TLS-TOE support which we don't want.

Oh, so it's completely incompatible with kernel tls. How about we
remove the support completely then? Clearly it's not an offload of
kernel tls if it supports completely different mode of operation.