Re: [PATCH v2] nvme-auth: Include SC_C in RVAL controller hash

[Hannes Reinecke]

On 4/27/26 01:22, Alistair Francis wrote:
> On Sat, Apr 25, 2026 at 8:58 AM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote:
> > On 16/04/2026 8:25, Alistair Francis wrote:
> > > On Thu, Apr 16, 2026 at 3:16 PM Christoph Hellwig <hch@xxxxxx> wrote:
> > > > On Thu, Apr 16, 2026 at 09:08:24AM +1000, alistair23@xxxxxxxxx wrote:
> > > > > From: Alistair Francis <alistair.francis@xxxxxxx>
> > > > >
> > > > > Section 8.3.4.5.5 of the NVMe Base Specification 2.1 describes what is
> > > > > included in the Response Value (RVAL) hash and SC_C should be included.
> > > > > Currently we are hardcoding 0 instead of using the correct SC_C value.
> > > > >
> > > > > Update the host and target code to use the SC_C when calculating the
> > > > > RVAL instead of using 0.
> > > > This looks correct.  But I guess this breaks existing implementations
> > > > in the wild now?
> > > It would break an implementation that is using non zero sc_c and
> > > updates one of the Linux target or Linux host but not the other.
> > >
> > > Note that similar changes have been made recently to "HostHost" and
> > > didn't seem to break everything
> > >
> > > 7e091add9c43 nvme-auth: update sc_c in host response
> > > 159de7a825ae nvmet-auth: update sc_c in target host hash calculation
> >
> > Still doesn't mean that it does not break folks.
>
> The current implementation breaks all cases of secure concat with a
> spec compliant implementation though, which does seem worse.
>
> > I don't see how we get around not breaking other than introducing some
> > compat mode under some sysctl (yukk).
>
> Ewww...
>
> > Perhaps secure-concatenation is new enough that the breakage surface
> > is very small.
>
> I suspect the user base right now is small to zero, especially
> considering that this won't work with any spec compliant
> implementation and no one else has noticed.
Precisely. Secure concatenation is still pretty new, and there are
very few implementations out there.
So I'm fine with not having a 'compat' setting.

Cheers,

Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@xxxxxxx                                +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