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

Message-ID: <48aaf181-b7cf-45d1-ba60-bf90ad45d842@oracle.com>
Date: Sat, 17 May 2025 12:39:58 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Steve Sears <sjs@...merspace.com>,
        Thomas Haynes <loghyr@...merspace.com>,
        kernel-tls-handshake <kernel-tls-handshake@...ts.linux.dev>,
        Sabrina Dubroca <sd@...asysnail.net>
Subject: Re: RPC-with-TLS client does not receive traffic

On 5/16/25 7:53 PM, Jakub Kicinski wrote:
> On Fri, 16 May 2025 23:38:18 +0000 Chuck Lever III wrote:
>>> On Thu, 15 May 2025 11:05:21 -0400 Chuck Lever wrote:  
>>>> It looks to me like the socket callbacks are set up correctly. If I
>>>> apply a patch to remove the msg_ready optimization from tls_data_ready,
>>>> everything works as expected.  
>>>
>>> The thinking is that we can stop reporting "data ready" once we have
>>> a data record, because reader must check for pre-existing data when
>>> starting to monitor the socket. I suspect when you say "everything
>>> works as expected" you mean that the next chunk of data coming in
>>> wakes the reader and reader catches up?
>>>
>>> Could you point me to the exact code path that handles the callback
>>> installation? Does it handle a socket with data in rcvq already?  
>>
>> I’m away from my plaintext MUA at the moment, so HTML only, I’m afraid.
>>
>> xs_tcp_tls_finish_connecting() is where the data_ready callback address is modified.
> 
> Hm, yes, my intuition would be to add a xs_poll_check_readable() 
> after connection set up to check if we raced with data being queued?
> 
> IIUC sk->sk_user_data is not set up when the first event fires
> so xs_data_ready() ignores it?  We can't set user_data sooner?

I think the answer to this is that sunrpc never sees a data ready event.
The value contained in sk->sk_user_data is therefore irrelevant.

Because tls_setsockopt() sets strp->msg_ready, when the underlying
socket event arrives tls_data_ready() is a no-op. That terminates the
 ->data_ready call chain before xs_data_ready can be called.

The handshake daemon sets the session key by calling tls_setsockopt.
When it hangs:

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    <<<<<

The next call to tls_data_ready sees strp->msg_ready is set, returns
without doing anything, and progress stops.

In the successful case, tls_strp_check_rcv() simply returns, leaving
strp->msg_ready set to zero. The next call to tls_data_ready can
then process the ingress data and call xs_data_ready.


-- 
Chuck Lever