Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Martin George <martinus.gpy@gmail.com>, linux-nvme@lists.infradead.org
Cc: hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, hare@kernel.org,
	Martin George <marting@netapp.com>
Subject: Re: [PATCH] nvme-tcp: send only permitted commands for secure concat
Date: Wed, 10 Sep 2025 14:58:19 +0200	[thread overview]
Message-ID: <1f7cd5e4-45f0-40cb-ab6a-6936a5062ae0@suse.de> (raw)
In-Reply-To: <20250909103509.10343-1-marting@netapp.com>

On 9/9/25 12:35, Martin George wrote:
> In addition to sending permitted commands such as connect/auth
> over the initial unencrypted admin connection as part of secure
> channel concatenation, the host also sends commands such as
> Property Get and Identify on the same. This is a spec violation
> leading to secure concat failures. Fix this by ensuring these
> additional commands are avoided on this connection.
> 
> Fixes: 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation")
> Signed-off-by: Martin George <marting@netapp.com>
> ---
>   drivers/nvme/host/tcp.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index c0fe8cfb7229..1413788ca7d5 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -2250,6 +2250,9 @@ static int nvme_tcp_configure_admin_queue(struct nvme_ctrl *ctrl, bool new)
>   	if (error)
>   		goto out_cleanup_tagset;
>   
> +	if (ctrl->opts->concat && !ctrl->tls_pskid)
> +		return 0;
> +
>   	error = nvme_enable_ctrl(ctrl);
>   	if (error)
>   		goto out_stop_queue;

Hmm. Not sure. While section 8.3.4.3 'NVMe In-band Authentication' states:

  If one or more of the bits in the AUTHREQ field are set to ‘1’, then
  the controller requires that the host authenticate on that queue in
  order to proceed with Fabrics, Admin, and I/O commands.

 From which one could assume that none of the commands are allowed.
But it then goes on to state:

  The state of an in-progress authentication transaction is soft-state.
  If the subsequent command in an authentication transaction is not
  received by the controller within a timeout equal to:
   * the Keep Alive Timeout value (refer to Figure 546), if the Keep
     Alive Timer is enabled; or
   * the default Keep Alive Timeout value (i.e., two minutes), if the
     Keep Alive Timer is disabled;

one can imply that KATO is running during authentication transactions.
But that might require additional commands, so really I'm not sure.
Let me ask FMDS for clarification.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@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


  reply	other threads:[~2025-09-10 12:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 10:35 [PATCH] nvme-tcp: send only permitted commands for secure concat Martin George
2025-09-10 12:58 ` Hannes Reinecke [this message]
2025-09-11 13:07   ` Martin George
2025-09-15 15:58     ` Hannes Reinecke
2025-09-15 16:25 ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f7cd5e4-45f0-40cb-ab6a-6936a5062ae0@suse.de \
    --to=hare@suse.de \
    --cc=hare@kernel.org \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=marting@netapp.com \
    --cc=martinus.gpy@gmail.com \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox