On 7/23/21 10:02 PM, Vladislav Bolkhovitin wrote:
Another comment is that better to perform CRC check of dhchap_secret and
generation of dhchap_key right where the secret was specified (e.g.,
nvmet_auth_set_host_key() on the target side).
No need to do it every time for every connection and by that increase
authentication latency. As I wrote in the other comment, it might be 128
or more connections established during connecting to a single NVMe-oF
device.
And this is something I did deliberately.
The primary issue here is that the user might want/need to change the
PSK for re-authentication. But for that he might need to check what the
original/current PSK is, so I think we need to keep the original PSK as
passed in from the user.
And I found it a waste of space to store the decoded secret in addition
to the original one, seeing that it can be derived from the original one.
But your argument about the many connections required for a single NVMe
association is certainly true, to it would make sense to keep the decode
one around, too, just to speed up computation.
Will be updating the patchset.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
