[PATCHv18 00/11] nvme: In-band authentication support

Hannes Reinecke hare at suse.de
Mon Jun 27 23:05:04 PDT 2022


On 6/27/22 23:34, Chaitanya Kulkarni wrote:
> On 6/27/22 02:51, Hannes Reinecke wrote:
>> Hi all,
>>
>> recent updates to the NVMe spec have added definitions for in-band
>> authentication, and seeing that it provides some real benefit
>> especially for NVMe-TCP here's an attempt to implement it.
>>
>> Thanks to Nicolai Stange the crypto DH framework has been upgraded
>> to provide us with a FFDHE implementation; I've updated the patchset
>> to use the ephemeral key generation provided there.
>>
>> Note that this is just for in-band authentication. Secure
>> concatenation (ie starting TLS with the negotiated parameters)
>> requires a TLS handshake, which the in-kernel TLS implementation
>> does not provide. This is being worked on with a different patchset
>> which is still WIP.
>>
>> The nvme-cli support has already been merged; please use the latest
>> nvme-cli git repository to build the most recent version.
>>
>> A copy of this patchset can be found at
>> git://git.kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel
>> branch auth.v17
>>
>> The patchset is being cut against nvme-5.20.
>>
> 
> I was able to run the V5 of blktets on this version see log below.
> 
> I am seeing few error messages when I run with tcp and loop,
> please have a look to make sure they are the expected ones.
> 
Yes, they are.
The point of authenticated conections is that they should fail
if the authentication credentials do not match.
So we need not only test the 'good' case, but also the 'bad' case
where a connection is expected to fail.
That is being tested in test 040.

Test 043 is similar, but here it's for re-authentication; and
again it needs to fail if the authentication credentials do not
match.

> In case they are expected ones lets filter them out since it will
> create confusion and people will start reporting these issues.
> 
Sure. If you tell me how.
These are kernel messages which I deem
necessary in 'normal' operations. It's in this particular context
where they are expected and should be ignored.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare at suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman



More information about the Linux-nvme mailing list