[RFC nvme-keyring nvme-cli] Should NVMe/TLS PSKs support the request_key API?

[Hannes Reinecke]

On 4/23/26 01:10, Chris Leech wrote:
> Would it be of interest to support the request_key API with NVMe/TLS
> PSKs? I think it would be an improvement, allowing PSKs to be loaded
> into the keyring as needed.
> 
Hehe. I knew someone would bring it up :-)

> Issues (if it was simple I'd just send a patch):
> 
>   - a key cannot have it's description changed
>   - request_key() creates an uninstantiated key with the description set
>   - tlshd (ktls-utils) uses the description as the PSK Identity
>   - NVMe specifies this Identity in a way that the kernel cannot know it
>     when a request_key() would be needed (it includes an encoding of the
>     key length and a digest of the source key it was derived from)
> 
That is correct.

> As nvme_keyring can't just request the key it needs, I went through a
> few ideas:
> 
>   - request a new keyring full of PSK keys
>     (requesting a keyring is explicitly blocked)
>   - have the user-space handler create a temporary keyring, put one or
>     more PSKs in it, and return the keyring serial in a "psk request key"
>     (worked, but seems unlikely to be accepted as intended use)
>   - have a request key format that expects to receive a key containing
>     one or more PSKs + identity metadata, unpack those in the kernel into
>     actual psk keys than can be used
> 
> I'm going to follow this with a _rough_ prototype of the last option in
> that list. The user-space side is a shell script, I'd replace that with
> an new nvme-cli command (but the request_key configuration does
> provide a convenient place to allow for other key storage solutions to
> hook in).
> 
> Motivation: The current solution for loading NVMe/TLS PSKs into the
> kernel keyring (70-nvmf-keys.rules in the nvme-cli repo) falls short in
> a few areas by triggering from a kmod load uevent:
> 
>   - doesn't work for the target modules
>     (that one's easy, /nvme_tcp/nvme_keyring/)
>   - doesn't work if the modules are built into the kernel
>   - doesn't work if the modules are loaded from initramfs, with more PSKs
>     and connections are configured outside of the nBFT
>   - only runs once, must load all keys and cannot help with new keys
>     (ok, nvme-cli doesn't have a command to save to a keyfile without
>      importing to the keyring first anyway)
> 
>   Biggest problem I see, requiring explicit loading of nvme_tcp before it
>   can be used with TLS:
> 
>   - The async uevent handling loses the race against the kernel when the
>     transport kmod is requested on demand.
> 
>    ┌────────┐     ┌──────────┐     ┌──────────┐     ┌──────┐
>    │ kernel │     │ nvme-cli │     │ modprobe │     │ udev │
>    └────┬───┘     └─────┬────┘     └─────┬────┘     └───┬──┘
>         │               │                │              │
>         │ connect       │                │              │
>         │◄──────────────┤                │              │
>         │               │                │              │
>         │ request kmod  │                │              │
>         ├───────────────────────────────►│              │
>         │               │                │              │
>         │ load kmod     │                │              │
>         │◄───────────────────────────────┤              │
>         │               │                │              │
>         │ uevent kmod   │                │              │
>         ├╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌►│
>         │               │                │              │
>         │ check keyring for PSK ❌       │              │
>         ├──┐            │                │              │
>         │  │            │                │              │
>         │◄─┘            │                │              │
>         │               │                │              │
>         │ connect failed ❌              │              │
>         ├──────────────►│                │              │
>         │               │                │              │
>         │               │ nvme tls --import --keyfile   │
>         │               │◄──────────────────────────────┤
>         │               │                │              │
>         │ populate .nvme keyring         │              │
>         │◄──────────────┤                │              │
>         │               │                │              │
> 
> - Chris
>
(Nice ASCII graphic, btw :-)

I know, the current model is ever so imperfect.
And relying on udev _module_ events clearly requires them
to be modules in the first place.
(Fun fact: I am rather positive that we _do_ get the module
uevents even when built in, it's just that they'll be issues
right at the start of the kernel where no udev (nor any userspace)
is available to process them ...)

But anyway; why can't we tweak nvmf-autoconnect.service to load
the keys?

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