[PATCH v2 3/4] nvme: Expose the tls_configured sysfs for secure concat connections

[Alistair Francis]

On Thu, Nov 13, 2025 at 5:21 PM Hannes Reinecke <hare at suse.de> wrote:
>
> On 11/13/25 03:08, Alistair Francis wrote:
> > On Wed, Nov 12, 2025 at 5:08 PM Hannes Reinecke <hare at suse.de> wrote:
> >>
> >> On 11/12/25 00:45, alistair23 at gmail.com wrote:
> >>> From: Alistair Francis <alistair.francis at wdc.com>
> >>>
> >>> Signed-off-by: Alistair Francis <alistair.francis at wdc.com>
> >>> ---
> >>> v2:
> >>>    - New patch
> >>>
> >>>    drivers/nvme/host/sysfs.c | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
> >>> index 29430949ce2f..6d10e12136d0 100644
> >>> --- a/drivers/nvme/host/sysfs.c
> >>> +++ b/drivers/nvme/host/sysfs.c
> >>> @@ -838,7 +838,7 @@ static umode_t nvme_tls_attrs_are_visible(struct kobject *kobj,
> >>>            !ctrl->opts->tls && !ctrl->opts->concat)
> >>>                return 0;
> >>>        if (a == &dev_attr_tls_configured_key.attr &&
> >>> -         (!ctrl->opts->tls_key || ctrl->opts->concat))
> >>> +         !ctrl->opts->concat)
> >>>                return 0;
> >>>        if (a == &dev_attr_tls_keyring.attr &&
> >>>            !ctrl->opts->keyring)
> >>
> >> ??
> >>
> >> How can you have a configured TLS Key for secure concatenation?
> >
> > I'm not sure I follow
> >
> > `ctrl->opts->tls_key` is directly set at the end of the
> > `nvme_auth_secure_concat()` function, so it will be set for secure
> > concatenation.
> >
> Right, sorry. Of course you are right.
>
> But I'm still a bit unsure about the interface here; just writing
> anything into it doesn't feel like the correct way of doing it.

I'm happy to change that.

I was thinking a bool, so basically write 1 to trigger

>
> I would rather modify the interface to allow a key serial number (or 0).
> That would allow us to modify the configured key, which currently is
> fixed for the lifetime of the connection.

Wouldn't a configured key (`tls_key`) be changed via the tlshd
interface, not writing a key serial to sysfs?

> And writing '0' would reset the configured key, reverting to automatic
> key selection.
> Having such an interface would actually be beneficial, as it would
> remove some limitations from the current interface.

Anyway, I'm not sure your vision conflicts with allowing "write 1 to
`tls_configured_key` to trigger a REPLACETLSPSK"

Alistair

>
> Hmm?
>
> 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