linux-kernel - Re: [PATCH 3/3] nvme: Allow reauth from sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKmqyKNZj6gwPOBrjRk_vTJqpUTPTsHF5S0iQPgVPi4+NHP7uQ@mail.gmail.com>
Date: Thu, 13 Nov 2025 14:01:30 +1000
From: Alistair Francis <alistair23@...il.com>
To: Hannes Reinecke <hare@...e.de>
Cc: Christoph Hellwig <hch@....de>, kbusch@...nel.org, axboe@...nel.dk, sagi@...mberg.me, 
	kch@...dia.com, linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH 3/3] nvme: Allow reauth from sysfs

On Wed, Nov 12, 2025 at 5:21 PM Hannes Reinecke <hare@...e.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@...e.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