Re: [PATCH 0/1] NVMe/TLS connection issues to SPDK

[Hannes Reinecke <hare@suse.de>]

On 7/21/25 17:44, Chris Leech wrote:
> On Mon, Jul 21, 2025 at 09:11:22AM +0200, Hannes Reinecke wrote:
>> On 7/21/25 04:17, Chris Leech wrote:
>>> ...
>>> The NVMe/TCP host driver then quickly fails when SPDK sends a TLS "New
>>> Session Ticket" message before ICResp.
>>>
>>> While possibly pointless due to the transport specification prohibition
>>> on session resumption and 0-RTT data, I don't think this is necessarily
>>> wrong and the host driver should be able to safely ignore it and
>>> continue.
>>>
>> Sigh. The neverending discussion.
>> Originally I didn't implement key update for NVMe as neither gnutls nor
>> the kernel supported it.
>> Turns out that key update was implemented last year for ktls, and gnutls
>> has support functions (gnutls_session_key_update()) for this, too.
>> So we _could_ start looking into it if nvme wouldn't be using the
>> ->read_sock() interface.
>> This interface just works on skbs, and as such we can't easily get hold
>> on the TLS alert data required for figuring out if a New Session Ticket
>> message had been sent.
> 
> I think this is a bit different, as it's NewSessionTicket and not
> KeyUpdate. NewSessionTicket seems to provide an age-limited PSK for
> session resumption, allowing additional connections or re-connections to
> bypass an expensive certificate handshake. We're only using retained
> PSKs and prohibited from session resumption, so while spdk probably
> shouldn't be sending NewSessionTicket it should also safe for the host
> to just filter it out of the data stream and never use it.
> 
Ah, the NewSessionTicket thingie. Yes, that's completely pointless for
NVMe, as we _never_ re-use tickets for session re-establishment.
We only ever have one session, so the use-case of several short-lived
sessions doesn't apply here.

But with the current ->read_sock based receive workflow we
cannot filter out TLS NewSession messages from the NVMe layer
as we don't have access to the TCP stream itself.
So either we switch to a recvmsg() based workflow or we
need to modify the read_sock() implementation in net/tls
to filter out the NewSession message there.

Personally I'd rather switch over to recvmsg() as I never
liked the read_sock() interface anyway.
But that's my personal opinion; others may have different ideas.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.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