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

[Alistair Francis]

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.

Alistair