On 5/6/25 8:35 AM, 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? As Hannes mentioned in another email, that is the ultimate goal, and there may already be some code to do that. > For NFS hardcoding the keys and certs in tlshd.conf is even more anoying, > because it limits to a single client key and cert for the entire system. IIRC the keyring mechanism will work with NFS too. > I have a hacky little patch for the NFS client to pass keyids for the > client key and the certificate as mount options, which seems to work > nicely, but it still requires adding another keyring (see above) or > giving the user read permissions for the keys while it would prefer > that it would just work and we would not need to give any root login > session a way to read the keys. No-one has claimed that the current implementation is complete. I've just sort of petered out on significant new changes. But it's definitely still open to contribution. Patches on kernel-tls-handshake@ are very welcome. (But you do have to sign the Oracle Contributor's Agreement, unfortunately, to get the patches into ktls-utils). -- Chuck Lever
