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

[Sagi Grimberg]

On 06/05/2025 15: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?
>
> 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.
>
> 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.
>

Christoph,

Just so I understand, this is a separate issue from passing the keyring to
tlshd correct? Is the suggesting that nfs will create a special .nfs keyring
similar to what nvme does?

Note that nvme also allows the user to pass its own keyring (never tried
it before - we probably need a blktest for it //hannes). So in this 
case, the
possessor will need to set user READ perms on the key itself (assuming that
it updated tlshd.conf to know this keyring)?