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

[Sagi Grimberg]

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.

I don't see how we get around not breaking other than introducing some
compat mode under some sysctl (yukk).

Perhaps secure-concatenation is new enough that the breakage surface
is very small.

> Alistair