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

[Chuck Lever]

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