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-next>] [day] [month] [year] [list]
Message-ID: <0288b61b-6a8e-409d-8e4c-3f482526cf46@oracle.com>
Date: Thu, 15 May 2025 10:35:57 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: 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>
Subject: RPC-with-TLS client does not receive traffic

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.

-- 
Chuck Lever


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ