From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57DD3383326 for ; Mon, 11 May 2026 23:12:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778541132; cv=none; b=d5IPGKm5FL88/GOpR2dWwLMM6Vpn4IWxHfFYoVsGUgxH7haMFYRnVLaC8mxQBaWzMLOoQvsEz7nw8R+aHRqW31NR5b3o4Y+84mQF/W6mHj3+MoTCTvp3CKxhj6EGos7Tw7r1JZHWs4e2+Rt04TDW1+IG8775XZ23yCoU1g2lmXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778541132; c=relaxed/simple; bh=aOERcIU/jFHzO/xWFj9O/Ookh4+6ChCIXRn2aWz3RTk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UKhA0+9Bc0phH1Q039ah9YWhyKl1O/4zzmNst8PC7iwRONoUE7LkITcsK2MzsBHzd5ucAjtvF/YxaKdzoNyBeNhXC+TkY9i1y7Q7rzAF9+nFXa0q1yJZCEak5RC+u0ph1Yugk3y9B8rwpXS9FwxgMUaZLXTtJRxzmEtsyvu5j2A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OL8HT2h6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OL8HT2h6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7A1C9C2BCB0; Mon, 11 May 2026 23:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778541131; bh=aOERcIU/jFHzO/xWFj9O/Ookh4+6ChCIXRn2aWz3RTk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OL8HT2h6+n4/D4+JUu1dUwZOLtY9GRv8PnIih+t2qYnRv9j5+m1F4LgmZya+pjDZ5 jePgg4N2em5p/e+SvVGJWymEKSnxM6Q+6HlMu1spw32bph9fxTVfIEBkCXzAzNsnit nQ5zITK/CPhW/z17EoO71kDWUZhIC33JAGmqk0IysqnH0GYh///xKXFx+TozAOPixp lLEzbxDUrqY2hImsfZ5F2LNITY9i2SHthVSQX/wYGjn0PaWbE2VndTyhEwMqNfJ9h8 JKVoj2TXzAtdqIZPdlv9eOUVNjJ0q3hgpw6DQvqaedvUo6Ijlo7X56O4gVve/4XtRi tS32BBAKiJ57w== Message-ID: Date: Tue, 12 May 2026 08:12:08 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] nvme/tcp: handle rejected keys for secure concatnation To: Wilfred Mallawa , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, alistair.francis@wdc.com, Wilfred Mallawa References: <20260511005454.2486599-2-wilfred.opensource@gmail.com> Content-Language: en-US From: Damien Le Moal Organization: Western Digital Research In-Reply-To: <20260511005454.2486599-2-wilfred.opensource@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/11/26 09:54, Wilfred Mallawa wrote: > From: Wilfred Mallawa > In the title: s/concatnation/concatenation > The NVMe-TCP specification [1] states that if the PSK retained or > generated is not available on the subsystem, the TLS 1.3 handshake shall > be aborted with an unknown_psk_identity alert and the connection be > closed. > > Currently, when an unknown_psk_identity alert is sent from an endpoint, > tlshd returns EACCES as the TLS error. On subsequent reconnection > attempts, we fail with the same error because we keep attempting to > connect with a stale key. This may occur if the endpoint experienced a > full reset and lost its PSK. > > With support in tlshd to return -EKEYREJECTED when an unknown_psk_identity > alert is received, the kernel can now detect this condition and revoke the > current tls_key. This allows the subsequent reconnect to perform > re-authentication via DHCHAP to generate a fresh PSK. > > [1] https://nvmexpress.org/wp-content/uploads/NVM-Express-TCP-Transport-Specification-Revision-1.1-2024.08.05-Ratified.pdf > > Signed-off-by: Wilfred Mallawa > --- > drivers/nvme/host/tcp.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c > index 15d36d6a728e..eff68eb7a5fe 100644 > --- a/drivers/nvme/host/tcp.c > +++ b/drivers/nvme/host/tcp.c > @@ -1767,6 +1767,17 @@ static int nvme_tcp_start_tls(struct nvme_ctrl *nctrl, > dev_err(nctrl->device, > "queue %d: TLS handshake complete, error %d\n", > qid, queue->tls_err); > + > + /* > + * Key maybe stale, revoke it such that on a subsequent * If the key is stale, revoke it... > + * reconnect, we will generate a new PSK. > + */ > + if (queue->tls_err == EKEYREJECTED && qid == 0 && > + nctrl->opts->concat && nctrl->opts->tls_key) { > + nvme_auth_revoke_tls_key(nctrl); > + dev_warn(nctrl->device, > + "qid 0: revoking stale key\n"); > + } > } else { > dev_dbg(nctrl->device, > "queue %d: TLS handshake complete\n", qid); -- Damien Le Moal Western Digital Research