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: <20201109105851.41417807@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ