From: Keith Busch <kbusch@kernel.org>
To: Hannes Reinecke <hare@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCHv15 00/10] nvme: implement secure concatenation
Date: Fri, 28 Feb 2025 15:41:24 -0700 [thread overview]
Message-ID: <Z8I7lA76zuE3LSm8@kbusch-mbp> (raw)
In-Reply-To: <20250224123818.42218-1-hare@kernel.org>
On Mon, Feb 24, 2025 at 01:38:08PM +0100, Hannes Reinecke wrote:
> From: Hannes Reinecke <hare@suse.de>
>
> Hi all,
>
> here's my attempt to implement secure concatenation for NVMe-of TCP
> as outlined in TP8018 / NVMe Base Spec v2.1.
> The original (v5) patchset had been split in two, the first part of
> which has already been merged with nvme-6.11, and this is the second part
> which actually implements secure concatenation.
>
> Secure concatenation means that a TLS PSK is generated from the key
> material negotiated by the DH-HMAC-CHAP protocol, and the TLS PSK
> is then used for a subsequent TLS connection.
> With NVMe v2.1 the connection has to be reset after DH-HMAC-CHAP
> negotiation, and the new connection can then be started with TLS
> encryption using the generated TLS PSK.
>
> To implement that Sagi came up with the idea to directly reset the
> admin queue once the DH-CHAP negotiation has completed; that way
> it will be transparent to the upper layers and we don't have to
> worry about exposing queues which should not be used.
Queued up in nvme-6.15, thanks.
prev parent reply other threads:[~2025-02-28 22:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 12:38 [PATCHv15 00/10] nvme: implement secure concatenation Hannes Reinecke
2025-02-24 12:38 ` [PATCH 01/10] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke
2025-02-24 12:38 ` [PATCH 02/10] nvme: add nvme_auth_generate_psk() Hannes Reinecke
2025-02-24 12:38 ` [PATCH 03/10] nvme: add nvme_auth_generate_digest() Hannes Reinecke
2025-02-24 12:38 ` [PATCH 04/10] nvme: add nvme_auth_derive_tls_psk() Hannes Reinecke
2025-02-24 12:38 ` [PATCH 05/10] nvme-keyring: add nvme_tls_psk_refresh() Hannes Reinecke
2025-02-24 12:38 ` [PATCH 06/10] nvme-tcp: request secure channel concatenation Hannes Reinecke
2025-02-24 12:38 ` [PATCH 07/10] nvme-fabrics: reset admin connection for secure concatenation Hannes Reinecke
2025-02-24 12:38 ` [PATCH 08/10] nvmet: Add 'sq' argument to alloc_ctrl_args Hannes Reinecke
2025-02-24 22:10 ` Damien Le Moal
2025-02-25 7:45 ` Sagi Grimberg
2025-02-24 12:38 ` [PATCH 09/10] nvmet-tcp: support secure channel concatenation Hannes Reinecke
2025-02-24 12:38 ` [PATCH 10/10] nvmet: add tls_concat and tls_key debugfs entries Hannes Reinecke
2025-02-28 22:41 ` Keith Busch [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=Z8I7lA76zuE3LSm8@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-nvme@lists.infradead.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.