[PATCH 12/18] nvme-fabrics: parse options 'keyring' and 'tls_key'

[Hannes Reinecke]

On 4/3/23 14:24, Sagi Grimberg wrote:
>>>> Parse the fabrics options 'keyring' and 'tls_key' and store the
>>>> referenced keys in the options structure.
>>>
>>> Can you explain the reasoning to why a user need to pass a keyring
>>> given that we already set up one?
>>>
>> Choice.
>> With a single keyring we can only have a single identity.
>> But there might be configurations where we want to have different PSKs
>> for the same identity (eg for key rotation).
> 
> How do you expect that rotation would work with this?
> 
The user creates a new keyring, adds the necessary keys to it, and then
either
- updates the keyring for nvmet (via configfs)
or
- reconnects using the new keyring

> How does nvmet handle a non-nvme keyring?
> 
There is a configfs attribute 'param_keyring', allowing you to use a 
different keyring (the nvme one is just the default).

>> With this option we can prepare a new keyring, and use that instead of 
>> the old one.
> 
> On an existing controller?
> 
Sure; when we are updating the keyring and the key id the controller 
will use that after the next reset.
Much like we do for DH-CHAP nowadays.

>> (And it really doesn't add much complexity...)
> 
> I know, it just adds one more argument, and I want to understand if it
> is really needed.

I do agree that the keyring argument would not necessarily required if 
we pass in the key id, but I'll be needing the keyring for secure 
concatenation. And plan is to move DH-HMAC-CHAP over to keyrings, too.

So I'd prefer to keep it.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg
Managing Directors: I. Totev, A. Myers, A. McDonald, M. B. Moerman
(HRB 36809, AG Nürnberg)