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

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: <CAKmqyKOtg9EE-hUCw_g9W10BfoHjsEZnYaum1r9-F+h2S=nurQ@mail.gmail.com>
Date: Fri, 14 Nov 2025 13:47:13 +1000
From: Alistair Francis <alistair23@...il.com>
To: Hannes Reinecke <hare@...e.de>
Cc: kbusch@...nel.org, axboe@...nel.dk, hch@....de, sagi@...mberg.me, 
	kch@...dia.com, linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH v2 3/4] nvme: Expose the tls_configured sysfs for secure
 concat connections

On Thu, Nov 13, 2025 at 10:45 PM Hannes Reinecke <hare@...e.de> wrote:
>
> On 11/13/25 13:22, Alistair Francis wrote:
> > On Thu, Nov 13, 2025 at 5:21 PM Hannes Reinecke <hare@...e.de> wrote:
> >>
> >> On 11/13/25 03:08, Alistair Francis wrote:
> >>> On Wed, Nov 12, 2025 at 5:08 PM Hannes Reinecke <hare@...e.de> wrote:
> >>>>
> >>>> On 11/12/25 00:45, alistair23@...il.com wrote:
> >>>>> From: Alistair Francis <alistair.francis@....com>
> >>>>>
> >>>>> Signed-off-by: Alistair Francis <alistair.francis@....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 like to keep the interface consistent, so as it's displaying
> a key serial number it should also accept a key serial number on writing.
> (Or '0', which is 'invalid key serial number');

But you don't know what the new key serial will be

>
> >>
> >> 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?
> >
>
> We would need to figure out the effects of REPLACETLSPSK with secure
> concatenation.
> Clearly for secure concatenation the resulting key is generated from
> the secure key material negotiated during authentication. So the only
> valid keys here should be generated keys, not persistent ones.
> But in order to have _new_ generated keys we need to run authentication.
> Consequently the key serial number can't be known when starting a
> REPLACETLSPSK operation, and we need to write '0' into the
> tls_configured_key attribute to a) reset the generated key and b)
> start the authentication protocol.
> That will then generate a new key, which will be visible via
> 'tls_configured_key'.
>
> So all good, methinks.

Ok, so trigger a REPLACETLSPSK when the user writes `0` to
`tls_configured_key`. I can do that

Alistair

>
> >> 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"
> >
>
> Please don't use '1'. As mentioned earlier, I would like the sysfs
> attribute to represent entries in the keystore (by displaying the key
> serial number). '1' _is_ a valid number, and so the interface will try
> to lookup a key with serial number '1'.
> (And failing to do so :-)
> '0' is _not_ valid key serial number, so writing '0' is equivalent to
> 'disable that key'.
>
> 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