kernel TLS configuration, was: Re: [ANNOUNCE] ktls-utils 1.0.0

[Hannes Reinecke]

On 5/6/25 14:35, Christoph Hellwig wrote:
> Hi Chuck,
> 
> let me use this as a vehicle to rant^H^H^H^Hprovide constructive
> feedback about configuration of the tls upcalls now that I finally
> got around playing with both NVMe and TCP over TLS.
> 
> For modular systems configuations the amount of monolithic state
> in tlshd.conf is a bit unfortunate.
> 
> For NVMe it isn't all that bad, but having to hardcode the .nvme
> keyring still means that:
> 
>   - we need userspace configuration past just enabling tlshd to enable
>     any kernel subsystem using TLS upcalls.
>   - hard code the keyring used in the userspace configuration
> 
> Can't we ensure the upcall passes the keyring to use and avoid
> this issue entirely?
> 
Hmm. We do that already:

         dev_dbg(nctrl->device, "queue %d: start TLS with key %x\n",
                 qid, pskid);
         memset(&args, 0, sizeof(args));
         args.ta_sock = queue->sock;
         args.ta_done = nvme_tcp_tls_done;
         args.ta_data = queue;
         args.ta_my_peerids[0] = pskid;
         args.ta_num_peerids = 1;
         if (nctrl->opts->keyring)
                 keyring = key_serial(nctrl->opts->keyring);
         args.ta_keyring = keyring;
         args.ta_timeout_ms = tls_handshake_timeout * 1000;
         queue->tls_err = -EOPNOTSUPP;
         init_completion(&queue->tls_complete);
         ret = tls_client_hello_psk(&args, GFP_KERNEL);

... but we never evaluate the 'keyring' parameter from tlshd.
Should be easy enough to fix.

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