[PATCH] nvme-auth: Include SC_C in RVAL controller hash
Alistair Francis
alistair23 at gmail.com
Wed Mar 18 21:23:52 PDT 2026
On Thu, Mar 19, 2026 at 2:48 AM Hannes Reinecke <hare at suse.de> wrote:
>
> On 3/18/26 17:40, Chris Leech wrote:
> > On Tue, Mar 17, 2026 at 01:13:30PM +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.
> >
> > Am I correct in reading this, the current kernel implementation is out
> > of spec when doing secure channel concatenation (SC_C != 0) with
> > bidirectional authentication (R1 takes SC_C into account, but not R2)?
> >
> I certainly never tested secure concatenation with bi-directional
> authentication (seem to have fallen into the same trap as Martin
> George). So the chance of regression is rather small.
> When you fix it, pleas add a test-case for blktests, too, such
> that we extend test coverage for this particular corner-case.
Ok, I'll add a blktest test-case
Alistair
>
> 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
More information about the Linux-nvme
mailing list