netdev - Re: RPC-with-TLS client does not receive traffic

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: <62cbd258-11df-4d76-9ab1-8e7b72f01ca4@suse.de>
Date: Thu, 15 May 2025 17:02:03 +0200
From: Hannes Reinecke <hare@...e.de>
To: Chuck Lever <chuck.lever@...cle.com>, Jakub Kicinski <kuba@...nel.org>,
 Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Steve Sears <sjs@...merspace.com>,
 Thomas Haynes <loghyr@...merspace.com>,
 Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
 kernel-tls-handshake <kernel-tls-handshake@...ts.linux.dev>
Subject: Re: RPC-with-TLS client does not receive traffic

On 5/15/25 16:44, Chuck Lever wrote:
> Resending with linux-nfs and kernel-tls-handshake on Cc
> 
> 
> On 5/15/25 10:35 AM, Chuck Lever wrote:
>> Hi -
>>
>> I'm troubleshooting an issue where, after a successful handshake, the
>> kernel TLS socket's data_ready callback is never invoked. I'm able to
>> reproduce this 100% on an Atom-based system with a Realtek Ethernet
>> device. But on many other systems, the problem is intermittent or not
>> reproducible.
>>
>> The problem seems to be that strp->msg_ready is already set when
>> tls_data_ready is called, and that prevents any further processing. I
>> see that msg_ready is set when the handshake daemon sets the ktls
>> security parameters, and is then never cleared.
>>
>> function:             tls_setsockopt
>> function:                do_tls_setsockopt_conf
>> function:                   tls_set_device_offload_rx
>> function:                   tls_set_sw_offload
>> function:                      init_prot_info
>> function:                      tls_strp_init
>> function:                   tls_sw_strparser_arm
>> function:                   tls_strp_check_rcv
>> function:                      tls_strp_read_sock
>> function:                         tls_strp_load_anchor_with_queue
>> function:                         tls_rx_msg_size
>> function:                            tls_device_rx_resync_new_rec
>> function:                         tls_rx_msg_ready
>>
>> For a working system (a VMware guest using a VMXNet device), setsockopt
>> leaves msg_ready set to zero:
>>
>> function:             tls_setsockopt
>> function:                do_tls_setsockopt_conf
>> function:                   tls_set_device_offload_rx
>> function:                   tls_set_sw_offload
>> function:                      init_prot_info
>> function:                      tls_strp_init
>> function:                   tls_sw_strparser_arm
>> function:                   tls_strp_check_rcv
>>
>> The first tls_data_ready call then handles the waiting ingress data as
>> expected.
>>
>> Any advice is appreciated.
>>
> 
I _think_ you are expected to set the callbacks prior to do the tls 
handshake upcall (at least, that's what I'm doing).
It's not that you can (nor should) receive anything on the socket
while the handshake is active.
If it fails you can always reset them to the original callbacks.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@...e.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich