public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Daniel Wagner <wagi@kernel.org>, Keith Busch <kbusch@kernel.org>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: expose TLS mode
Date: Tue, 7 Apr 2026 12:47:57 +0200	[thread overview]
Message-ID: <77b7fc41-840e-43cc-a417-cbd78a9ba6aa@suse.de> (raw)
In-Reply-To: <20260401-expose-tls-mode-v1-1-433a83d1d23f@kernel.org>

On 4/1/26 10:52, Daniel Wagner wrote:
> It is not possible to determine the active TLS mode from the
> presence or absence of sysfs attributes like tls_key,
> tls_configured_key, or dhchap_secret.
> 
> With the introduction of the concat mode and optional DH-CHAP
> authentication, different configurations can result in identical
> sysfs state. This makes user space detection unreliable.
> 
> Expose the TLS mode explicitly to allow user space to
> unambiguously identify the active configuration and avoid
> fragile heuristics in nvme-cli.
> 
> Signed-off-by: Daniel Wagner <wagi@kernel.org>
> ---
> I am extending the test suite for nvme-cli to cover the use case of
> nvme connect --tls/--concat.
> 
> Currently, nvme-cli uses heuristics to determine whether --tls was used
> to initiate the connection. With the introduction of --concat, these
> heuristics are no longer reliable.
> 
> By exposing the TLS mode explicitly, nvme config can now generate a
> configuration based on the currently active connection.
> 
> $ nvme config --scan --dump --output-format json /dev/nvme1
> [
>    {
>      "hostnqn":"nqn.2014-08.org.nvmexpress:uuid:befdec4c-2234-11b2-a85c-ca77c773af36",
>      "hostid":"befdec4c-2234-11b2-a85c-ca77c773af36",
>      "dhchap_key":"DHHC-1:01:1+pb0VSbn3cBrOhwP5SHa6gwlbPikdZ0mmBKKXC74Sm0s0pb:",
>      "subsystems":[
>        {
>          "nqn":"nqn.io-1",
>          "ports":[
>            {
>              "transport":"tcp",
>              "traddr":"192.168.30.30",
>              "trsvcid":"4420",
>              "dhchap_key":"DHHC-1:01:1+pb0VSbn3cBrOhwP5SHa6gwlbPikdZ0mmBKKXC74Sm0s0pb:",
>              "dhchap_ctrl_key":"DHHC-1:01:uTcIEwLZsEoVJucx7sKVvzfwOTAfJ9ZGcvYWswHwF41mMSW1:",
>              "tls":true,
>              "keyring":".nvme"
>            }
>          ]
>        }
>      ]
>    }
> ]
> ---
>   drivers/nvme/host/sysfs.c | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)
> 
> diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c
> index 16c6fea4b2db..c4b5241371d6 100644
> --- a/drivers/nvme/host/sysfs.c
> +++ b/drivers/nvme/host/sysfs.c
> @@ -810,6 +810,23 @@ const struct attribute_group nvme_dev_attrs_group = {
>   EXPORT_SYMBOL_GPL(nvme_dev_attrs_group);
>   
>   #ifdef CONFIG_NVME_TCP_TLS
> +static ssize_t tls_mode_show(struct device *dev,
> +			     struct device_attribute *attr, char *buf)
> +{
> +	struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
> +	const char *mode;
> +
> +	if (ctrl->opts->tls)
> +		mode = "tls";
> +	else if (ctrl->opts->concat)
> +		mode = "concat";
> +	else
> +		mode = "none";
> +
> +	return sysfs_emit(buf, "%s\n", mode);
> +}
> +static DEVICE_ATTR_RO(tls_mode);
> +
>   static ssize_t tls_key_show(struct device *dev,
>   			    struct device_attribute *attr, char *buf)
>   {
> @@ -845,6 +862,7 @@ static struct attribute *nvme_tls_attrs[] = {
>   	&dev_attr_tls_key.attr,
>   	&dev_attr_tls_configured_key.attr,
>   	&dev_attr_tls_keyring.attr,
> +	&dev_attr_tls_mode.attr,
>   	NULL,
>   };
>   
> 
Why not modify the 'is_visible' function to hide the attribute
when TLS is not enabled?
That would avoid the awkward 'none' setting ...

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


      parent reply	other threads:[~2026-04-07 10:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-01  8:52 [PATCH] nvme: expose TLS mode Daniel Wagner
2026-04-01  9:04 ` Daniel Wagner
2026-04-01 14:09 ` Christoph Hellwig
2026-04-02  6:42   ` Daniel Wagner
2026-04-07  5:54     ` Christoph Hellwig
2026-04-07 10:47 ` Hannes Reinecke [this message]

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=77b7fc41-840e-43cc-a417-cbd78a9ba6aa@suse.de \
    --to=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=wagi@kernel.org \
    /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