[PATCH 3/3] nvme: Allow reauth from sysfs

[Alistair Francis]

On Wed, Nov 12, 2025 at 5:21 PM Hannes Reinecke <hare at suse.de> wrote:
>
> On 11/12/25 08:02, Christoph Hellwig wrote:
> > On Wed, Nov 12, 2025 at 09:32:00AM +1000, Alistair Francis wrote:
> >>> I would suggest just allow writes to the 'tls_key' attribute; any
> >>> writes to that would trigger a replacepsk operation.
> >>
> >> I think the `tls_configured_key` is actually the better attribute to
> >> write to as that is the one that updates after a REPLACETLSPSK
> >> operation, see v2 patches which I'm sending now.
> >
> > Just saw Hannes reply here and saw why you did the current version
> > the way I did.  Hannes, please don't recommend weird ABIs that
> > make error checking and future extensibility impossible.
> >
> Hmm.
>
> 'tls_configured_key' prints out the value of
> ctrl->opts->tls_key, ie the key passed in from the 'connect'
> string. Normally this value will be empty,
> as the 'connect' command will pick up the TLS key from
> the keyring automatically.

`tls_configured_key` does print out the value of
`ctrl->opts->tls_key`. That's the key that is generated in
`nvme_auth_secure_concat()`.

`ctrl->opts->tls_key` is also the key that changes after a
REPLACETLSPSK operation. `ctrl->opts->tls_key` is what's used in
nvme_auth_set_dhchap_negotiate_data() to determine if we should issue
a NEWTLSPSK or a REPLACETLSPSK.

So `ctrl->opts->tls_key` (and hence `tls_configured_key`) seems like
the way to go

>
> 'tls_key' prints out the value of
> ctrl->tls_pskid, ie the value of the _negotiated_ key.

Is it possible you have `ctrl->tls_pskid` and `ctrl->opts->tls_key` mixed up?

`ctrl->tls_pskid` is set by userspace via the nvme_tcp_tls_done()
callback. It's really more of the "configured" key as it's supplied by
userspace and doesn't change after a REPLACETLSPSK operation.

I'm not sure why the sysfs names are what they are, but
`tls_configured_key` seems like the negotiated key and `tls_key` is
configured by userspace.

>
> So why is 'tls_configured_key' key the better option?

`tls_configured_key` is the key that changes after a REPLACETLSPSK, so
it feels like that's the better place to trigger a REPLACETLSPSK.

> Personally I think that 'tls_key' is more 'natural',
> as we want to replace the negotiated key, not the
> configured key ...

I really think writing to the `tls_configured_key` to trigger a
REPLACETLSPSK is the way to go. It's the sysfs entry that changes
after a REPLACETLSPSK command. Writing to 'tls_key' and having it not
update just seems confusing.

Alistair

>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                  Kernel Storage Architect
> hare at suse.de                                +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