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

[Hannes Reinecke]

On 7/21/25 04:17, Chris Leech wrote:
> I was attempting to debug connecting the Linux driver / libnvme /
> ktls-utils host stack to the SPDK nvmf_tgt over TLS, and ran into some
> issues.
> 
> The TLS connection fails to complete a handshake because the TLS PSKs
> are different. The NVMe/TCP specified key derivation steps from the
> configured interchange format, to a retained PSK and finally the TLS
> PSK, is implemented incompatibly in libnvme and SPDK.  After some
> investigation, I believe the SPDK implementation to be correct and am
> providing a libnvme patch to match it. With libnvme modified, I see the
> TLS handshake complete in tlshd.
> 
> (Note that this was tested using the obsolete "version 0" PSK Identity
> and TLS PSK derivation from the TCP transport 1.0 specification, as SPDK
> has not been updated with the "version 1" changes)
> 
> 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 do have a patchset for converting that into a recvmsg() based
implementation, but that got shelved as we didn't have an efficient
iterator for data hashing. With the crc32 update from Eric Biggers
we now should have an iterator for crc32 data hashing, so I
guess I could revisit that.

Cheers,

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