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@xxxxxxx +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
