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

[Sagi Grimberg <sagi@grimberg.me>]

On 16/04/2026 8:25, Alistair Francis wrote:
> On Thu, Apr 16, 2026 at 3:16 PM Christoph Hellwig <hch@lst.de> wrote:
>> On Thu, Apr 16, 2026 at 09:08:24AM +1000, alistair23@gmail.com wrote:
>>> From: Alistair Francis <alistair.francis@wdc.com>
>>>
>>> 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