Re: Breakage in ktls-utils with nfs keyring?

["Chuck Lever" <cel@kernel.org>]

On Sun, May 3, 2026, at 10:37 PM, Sagi Grimberg wrote:
> On 03/05/2026 22:11, Chuck Lever wrote:
>>
>> On Sun, May 3, 2026, at 9:48 AM, Sagi Grimberg wrote:
>>> On 02/05/2026 6:08, Chuck Lever wrote:
>>>> On Fri, May 1, 2026, at 4:19 PM, Scott Mayhew wrote:
>>>>> On Thu, 30 Apr 2026, Chuck Lever wrote:

>>>>>    It seems
>>>>> like a lot more work than just using the config file.
>>> Well in some cases, storing credentials on a persistent file is not a
>>> viable option.
>>> For nvme there is a userspace utility that helps with this to some extent.
>> This is because handling an NVMe PSK in the keyring is a first-class,
>> supported mechanism. Handling the x.509 certificate this way hasn't
>> really been thought through.
>
> What makes NVMe PSK more "supported" than x.509?

Hannes contributed NVMe PSK in the beginning. IIUC PSK was the first
authentication mode available for the NVMe/TCP protocol. I'm not sure
we can say that x.509 is supported for our NVMe/TCP implementation,
though that is something that should be made to work someday.

Likewise for NFS and x.509 -- that was the easier authentication
mode to implement for RPC-with-TLS. Eventually we want to support
both.

It's simply a matter of development resources and priorities, there
is really no spec reason it cannot be done.


> The way I see it, use of a keyring most likely mean users rely on some
> automation software to populate it anyways.

Sure, but that software does not exist right now for NFS.

And with containery deployments, everyone likes to write their own
special scripts. Hard to say what exactly the nfs-utils-provided
pieces will need to implement.


>> You are also building tlshd from scratch rather than using a distro-
>> packaged version of it. That's rare enough, but it also means you can
>> apply the patch that fixes the issue and build it yourself.
>
> This breakage was brought to my attention by a user working on
> Ubuntu24.04 ktls-utils (1.3.0). It'd be better if we'd caught it sooner...

Full CI is something that is still in the works.


>> I'm open to considering a dot-release, but you haven't convinced me yet.
>
> Ultimately it's your call Chuck. But IMO we shouldn't hold out a fix
> for this until we are happy with a nicer mount.nfs interface.

I have to stop you there: That's completely not what I'm saying. No
one is holding back a fix -- it will be merged into the main branch
in a few days.

The question is whether this issue merits fresh upstream releases. As
I said, the capability isn't advertised, so at this time anyone who is
using this capability is doing so at their own risk. Whoever told you
this was a production-ready feature of the NFS client was mistaken. Can
you provide a key serial number on the mount command line? Yes. Is it
something that is tested and is the interface unchanging for all time?
No.

It wasn't clear that 1.3.0 was the problem. 1.4.0 was released just
last week, so that's where my attention was focused.

What you are asking for, then, is a 1.3.0 dot release for this fix. I
still don't feel there is a strong requirement for that, given that
distributions apply fixes to packages all the time. But I haven't made
a final call on that.


> Anyways, would be happy to contribute to this (don't know anything
> about the pq stuff though)...

Patches are absolutely welcome: post to kernel-tls-handshake, or
open PRs on github.


-- 
Chuck Lever