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
prev 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