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

[Sagi Grimberg]

>>> +        case NVMF_OPT_KEYRING:
>>> +            if (match_int(args, &key_id) || key_id <= 0) {
>>> +                ret = -EINVAL;
>>> +                goto out;
>>> +            }
>>> +            key = nvmf_parse_key(key_id, "Keyring");
>>> +            if (IS_ERR(key)) {
>>> +                ret = PTR_ERR(key);
>>> +                goto out;
>>> +            }
>>> +            key_put(opts->keyring);
>>
>> Don't understand how keyring/tls_key are pre-populated though...
>>
> They are not. But they might, as there's nothing in the code preventing 
> the user to specify 'keyring' or 'tls_key' several times.
> I can make it one-shot and error out if they are already populated, but
> really haven't seen the need.

OK, now I understand. its fine.

> 
>>> +            opts->keyring = key;
>>> +            break;
>>> +        case NVMF_OPT_TLS_KEY:
>>> +            if (match_int(args, &key_id) || key_id <= 0) {
>>> +                ret = -EINVAL;
>>> +                goto out;
>>> +            }
>>> +            key = nvmf_parse_key(key_id, "Key");
>>> +            if (IS_ERR(key)) {
>>> +                ret = PTR_ERR(key);
>>> +                goto out;
>>> +            }
>>> +            key_put(opts->tls_key);
>>> +            opts->tls_key = key;
>>> +            break;
>>>           case NVMF_OPT_DISCOVERY:
>>>               opts->discovery_nqn = true;
>>>               break;
>>> @@ -1168,6 +1216,8 @@ static int nvmf_check_allowed_opts(struct 
>>> nvmf_ctrl_options *opts,
>>>   void nvmf_free_options(struct nvmf_ctrl_options *opts)
>>>   {
>>>       nvmf_host_put(opts->host);
>>> +    key_put(opts->keyring);
>>> +    key_put(opts->tls_key);
>>>       kfree(opts->transport);
>>>       kfree(opts->traddr);
>>>       kfree(opts->trsvcid);
>>> diff --git a/drivers/nvme/host/fabrics.h b/drivers/nvme/host/fabrics.h
>>> index dac17c3fee26..fbaee5a7be19 100644
>>> --- a/drivers/nvme/host/fabrics.h
>>> +++ b/drivers/nvme/host/fabrics.h
>>> @@ -71,6 +71,8 @@ enum {
>>>       NVMF_OPT_DHCHAP_SECRET    = 1 << 23,
>>>       NVMF_OPT_DHCHAP_CTRL_SECRET = 1 << 24,
>>>       NVMF_OPT_TLS        = 1 << 25,
>>> +    NVMF_OPT_KEYRING    = 1 << 26,
>>> +    NVMF_OPT_TLS_KEY    = 1 << 27,
>>>   };
>>>   /**
>>> @@ -103,6 +105,8 @@ enum {
>>>    * @dhchap_secret: DH-HMAC-CHAP secret
>>>    * @dhchap_ctrl_secret: DH-HMAC-CHAP controller secret for 
>>> bi-directional
>>>    *              authentication
>>> + * @keyring:    Keyring to use for key lookups
>>> + * @tls_key:    TLS key for encrypted connections (TCP)
>>>    * @tls:        Start TLS encrypted connections (TCP)
>>>    * @disable_sqflow: disable controller sq flow control
>>>    * @hdr_digest: generate/verify header digest (TCP)
>>> @@ -130,6 +134,8 @@ struct nvmf_ctrl_options {
>>>       struct nvmf_host    *host;
>>>       char            *dhchap_secret;
>>>       char            *dhchap_ctrl_secret;
>>> +    struct key        *keyring;
>>> +    struct key        *tls_key;
>>>       bool            tls;
>>>       bool            disable_sqflow;
>>>       bool            hdr_digest;
>>> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
>>> index ef9cf8c7a113..f48797fcc4ee 100644
>>> --- a/drivers/nvme/host/tcp.c
>>> +++ b/drivers/nvme/host/tcp.c
>>> @@ -1589,6 +1589,8 @@ static int nvme_tcp_start_tls(struct nvme_ctrl 
>>> *nctrl,
>>>       dev_dbg(nctrl->device, "queue %d: start TLS with key %x\n",
>>>           qid, pskid);
>>> +    if (nctrl->opts->keyring)
>>> +        keyring = key_serial(nctrl->opts->keyring);
>>
>> Maybe populate opts->keyring with nvme_keyring_id() to begin
>> with and then you don't need this?
>>
> We could; one would lose the distinction between 'not specified' and
> 'specified with the defaul keyring', but one could argue whether that
> brings any benefit.

Not sure I understand.
What exactly is the distinction and how is it manifested?