linux-kernel - Re: [PATCH 1/1] nvme-fabrics: add ENOKEY to no retry criteria for authentication failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <788c2c3e-1293-447d-a43b-17d5026ce1db@flourine.local>
Date: Tue, 25 Nov 2025 11:34:40 +0100
From: Daniel Wagner <dwagner@...e.de>
To: Justin Tee <justintee8345@...il.com>
Cc: Hannes Reinecke <hare@...e.de>, linux-nvme@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, jsmart2021@...il.com, justin.tee@...adcom.com, 
	Daniel Wagner <wagi@...nel.org>
Subject: Re: [PATCH 1/1] nvme-fabrics: add ENOKEY to no retry criteria for
 authentication failures

Hi Justin,

On Mon, Nov 24, 2025 at 04:57:29PM -0800, Justin Tee wrote:
> Was under the impression that the issue with 041 is that there is a
> lingering reconnect attempt leftover from the “Test unauthenticated
> connection (should fail)” portion that interferes with the next “Test
> authenticated connection” portion of the blktest.

Yes, that was one part of the problem. FC keept continuing reconnecting
with an invalid key. The other transport would also try to reconnect
with an invalid key after the first initial connection. This is a long
standing problem and your patch fixes it for all transport.

As I said your fix is good and addresses the reconnect with an invalid
key problem. Though it doesn't address the issue that 'nvme connect'
will still return success.

> Through correcting the nvmf_should_reconnect routine, which stops
> retrying reconnect when -ENOKEY, there would be no interference in the
> second part of the test when nvme connect is with an actual key.  So,
> there will be a controller to nvme disconnect, as expected, for the
> “Test authenticated connection” portion of the test.

All the nvme tests which use 'nvme connect' do not check the return code
yet. Something I am going to add now. This should ensure that all the
transport behave from userpoint of view the same. There is no exception
for a transport to behave differently IMO. On the other hand we can't
break existing APIs, so we have to come up with an opt-in solution here.

Hope this makes it a bit more clearer.

Thanks a lot,
Daniel