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