From: Sagi Grimberg <sagi@grimberg.me>
To: Hannes Reinecke <hare@suse.de>, Hannes Reinecke <hare@kernel.org>,
Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>, linux-nvme@lists.infradead.org
Subject: Re: [PATCH 13/17] nvme-tcp: reset after recovery for secure concatenation
Date: Sun, 21 Apr 2024 14:22:27 +0300 [thread overview]
Message-ID: <0b2a2e0a-8003-4217-bdc5-af4d91ed9af2@grimberg.me> (raw)
In-Reply-To: <44ae1549-9d39-42d5-a6eb-a6700d4ab873@suse.de>
On 09/04/2024 1:10, Hannes Reinecke wrote:
> On 4/8/24 23:23, Sagi Grimberg wrote:
>>
>>
>> On 08/04/2024 9:25, Hannes Reinecke wrote:
>>> On 4/7/24 23:49, Sagi Grimberg wrote:
>>>>
>>>>
>>>> On 18/03/2024 17:03, Hannes Reinecke wrote:
>>>>> From: Hannes Reinecke <hare@suse.de>
>>>>>
>>>>> With TP8018 a new key will be generated from the DH-HMAC-CHAP
>>>>> protocol after reset or recovery, but we need to start over
>>>>> to establish a new TLS connection with the new keys.
>>>>>
>>>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>>>>> ---
>>>>> drivers/nvme/host/tcp.c | 20 ++++++++++++++++++++
>>>>> 1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
>>>>> index 94152ded123a..3811ee9cd040 100644
>>>>> --- a/drivers/nvme/host/tcp.c
>>>>> +++ b/drivers/nvme/host/tcp.c
>>>>> @@ -2219,6 +2219,22 @@ static void
>>>>> nvme_tcp_reconnect_or_remove(struct nvme_ctrl *ctrl)
>>>>> }
>>>>> }
>>>>> +static bool nvme_tcp_reset_for_secure_concat(struct nvme_ctrl *ctrl)
>>>>> +{
>>>>> + if (!ctrl->opts->concat)
>>>>> + return false;
>>>>> + /*
>>>>> + * If a key has been generated and TLS has not been enabled
>>>>> + * reset the queue to start TLS handshake.
>>>>> + */
>>>>> + if (ctrl->opts->tls_key && !ctrl->tls_key) {
>>>>> + dev_info(ctrl->device, "Reset to enable TLS with
>>>>> generated PSK\n");
>>>>> + nvme_reset_ctrl(ctrl);
>>>>> + return true;
>>>>> + }
>>>>> + return false;
>>>>> +}
>>>>> +
>>>>> static void nvme_tcp_revoke_generated_tls_key(struct nvme_ctrl
>>>>> *ctrl)
>>>>> {
>>>>> if (!ctrl->opts->concat)
>>>>> @@ -2321,6 +2337,9 @@ static void
>>>>> nvme_tcp_reconnect_ctrl_work(struct work_struct *work)
>>>>> if (nvme_tcp_setup_ctrl(ctrl, false))
>>>>> goto requeue;
>>>>> + if (nvme_tcp_reset_for_secure_concat(ctrl))
>>>>> + return;
>>>>> +
>>>>> dev_info(ctrl->device, "Successfully reconnected (%d
>>>>> attempt)\n",
>>>>> ctrl->nr_reconnects);
>>>>> @@ -2396,6 +2415,7 @@ static void nvme_reset_ctrl_work(struct
>>>>> work_struct *work)
>>>>> if (nvme_tcp_setup_ctrl(ctrl, false))
>>>>> goto out_fail;
>>>>> + nvme_tcp_reset_for_secure_concat(ctrl);
>>>>
>>>> This is really strange. I'd imagine that this would be needed only
>>>> if the derived psk expired no?
>>>
>>> You are absolutely correct. But once you reset the connection the
>>> derived PSK of the previous connection _is_ expired as DH-HMAC-CHAP
>>> generated a new one.
>>>
>>> Remember: for secure concatenation we _always_ have a two-step
>>> connection setup. The initial connection runs for DH-HMAC-CHAP
>>> to generate the PSK, and then a connection reset to start over
>>> with TLS and the generated PSK.
>>> So upon reset we have to invalidate the generated PSK, reset the
>>> connection to run DH-HMAC-CHAP, and reset _again_ to start over
>>> with the new PSK.
>>
>> So what is the point of setting the derived psk with a timeout?
>>
>> Seems rather silly doing that _every_ reset/reconnect... But ok...
>
> Mandated by TP8018. Generated TLS PSK should be renewed after a
> certain time. Makes sense in general, but still a pain.
I understand that psk can expire, I don't understand why we need to
reset every
single time. What if I'm doing the loop: while true; do nvme reset
/dev/nvme0; done?
Will it do 2 resets every time?
next prev parent reply other threads:[~2024-04-21 11:22 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 15:02 [PATCHv3 00/17] nvme: implement secure concatenation Hannes Reinecke
2024-03-18 15:03 ` [PATCH 01/17] nvme-keyring: restrict match length for version '1' identifiers Hannes Reinecke
2024-03-18 15:03 ` [PATCH 02/17] nvme-tcp: check for invalidated or revoked key Hannes Reinecke
2024-04-07 20:51 ` Sagi Grimberg
2024-04-08 5:18 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 03/17] crypto,fs: Separate out hkdf_extract() and hkdf_expand() Hannes Reinecke
2024-03-18 15:03 ` [PATCH 04/17] nvme: add nvme_auth_generate_psk() Hannes Reinecke
2024-04-07 20:59 ` Sagi Grimberg
2024-04-08 5:20 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 05/17] nvme: add nvme_auth_generate_digest() Hannes Reinecke
2024-04-07 21:02 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 06/17] nvme: add nvme_auth_derive_tls_psk() Hannes Reinecke
2024-04-07 21:04 ` Sagi Grimberg
2024-04-18 11:00 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 07/17] nvme-keyring: add nvme_tls_psk_refresh() Hannes Reinecke
2024-03-18 15:03 ` [PATCH 08/17] nvme-tcp: sanitize TLS key handling Hannes Reinecke
2024-04-07 21:15 ` Sagi Grimberg
2024-04-08 6:48 ` Hannes Reinecke
2024-04-08 21:07 ` Sagi Grimberg
2024-04-08 21:32 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 09/17] nvme-tcp: do not quiesce admin queue in nvme_tcp_teardown_io_queues() Hannes Reinecke
2024-04-07 21:24 ` Sagi Grimberg
2024-04-18 11:33 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 10/17] nvme: add a newline to the 'tls_key' sysfs attribute Hannes Reinecke
2024-04-07 21:24 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 11/17] nvme-tcp: request secure channel concatenation Hannes Reinecke
2024-04-07 21:41 ` Sagi Grimberg
2024-04-08 5:32 ` Hannes Reinecke
2024-04-08 21:09 ` Sagi Grimberg
2024-04-08 21:48 ` Hannes Reinecke
2024-04-21 11:14 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 12/17] nvme-fabrics: reset connection for secure concatenation Hannes Reinecke
2024-04-07 21:46 ` Sagi Grimberg
2024-04-08 6:21 ` Hannes Reinecke
2024-04-08 21:21 ` Sagi Grimberg
2024-04-08 22:08 ` Hannes Reinecke
2024-04-21 11:20 ` Sagi Grimberg
2024-05-08 9:21 ` Hannes Reinecke
2024-03-18 15:03 ` [PATCH 13/17] nvme-tcp: reset after recovery " Hannes Reinecke
2024-04-07 21:49 ` Sagi Grimberg
2024-04-08 6:25 ` Hannes Reinecke
2024-04-08 21:23 ` Sagi Grimberg
2024-04-08 22:10 ` Hannes Reinecke
2024-04-21 11:22 ` Sagi Grimberg [this message]
2024-04-21 14:37 ` Hannes Reinecke
2024-04-21 15:09 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 14/17] nvmet-auth: allow to clear DH-HMAC-CHAP keys Hannes Reinecke
2024-04-07 21:50 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 15/17] nvme-target: do not check authentication status for admin commands twice Hannes Reinecke
2024-04-07 21:53 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 16/17] nvme-target: do not check authentication status for I/O " Hannes Reinecke
2024-04-07 21:53 ` Sagi Grimberg
2024-03-18 15:03 ` [PATCH 17/17] nvmet-tcp: support secure channel concatenation Hannes Reinecke
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=0b2a2e0a-8003-4217-bdc5-af4d91ed9af2@grimberg.me \
--to=sagi@grimberg.me \
--cc=hare@kernel.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).