[PATCH 5/9] nvme/040: create an authenticated nvmeof-tcp connection

[Sagi Grimberg]

On 11/22/21 11:22 AM, Hannes Reinecke wrote:
> On 11/22/21 9:57 AM, Sagi Grimberg wrote:
>>
>>
>> On 11/22/21 9:55 AM, Hannes Reinecke wrote:
>>> Signed-off-by: Hannes Reinecke <hare at suse.de>
>>> ---
>>>    tests/nvme/040     | 64 ++++++++++++++++++++++++++++++++++++++++++++++
>>>    tests/nvme/040.out |  6 +++++
>>>    2 files changed, 70 insertions(+)
>>>    create mode 100644 tests/nvme/040
>>>    create mode 100644 tests/nvme/040.out
>>>
>>> diff --git a/tests/nvme/040 b/tests/nvme/040
>>> new file mode 100644
>>> index 0000000..9c2eb07
>>> --- /dev/null
>>> +++ b/tests/nvme/040
>>> @@ -0,0 +1,64 @@
>>> +#!/bin/bash
>>> +# SPDX-License-Identifier: GPL-3.0+
>>> +# Copyright (C) 2021 Hannes Reinecke, SUSE Labs
>>> +#
>>> +# Test nvme over tcp authentication
>>> +
>>> +. tests/nvme/rc
>>> +
>>> +DESCRIPTION="Create authenticated TCP connection via localhost"
>>> +QUICK=1
>>> +
>>> +requires() {
>>> +    _nvme_requires
>>> +    _have_modules loop
>>> +    _require_nvme_trtype_is_fabrics
>>> +}
>>> +
>>> +
>>> +test() {
>>> +    local port
>>> +    local genctr
>>> +    local subsys="blktests-subsystem-"
>>> +    local hostid="$(uuidgen)"
>>> +    local hostnqn="nqn.2014-08.org.nvmexpress:uuid:${hostid}"
>>> +    local scratch="/tmp/blktest-ns1.img"
>>> +    local nvme_trtype="tcp"
>>
>> Why is this tcp specific? what prevents this from passing with
>> loop/rdma?
>>
> 
> Nothing in principle.
> 
>> AFAICT the rest of the tests are not tcp specific either, nor
>> is inband auth in general...
>>
>> I think we should have the tests run with a user-defind nvme_trtype.
>>
> 
> If you can tell me how to do that I'll happily make the change.

Remove the above setting for nvme_trtype=tcp and verify the test
is fine using:

$ nvme_trtype=[tcp|loop|rdma] ./check tests/nvme/040

> 
>>> +    local hostkey
>>> +
>>> +    echo "Running ${TEST_NAME}"
>>> +
>>> +    hostkey="$(nvme gen-dhchap-key -n ${subsys}1 2> /dev/null)"
>>> +    if [ $? -ne 0 ] ; then
>>> +        echo "nvme gen-dhchap-key command missing"
>>> +        return 1
>>> +    fi
>>
>> I think that this belongs in nvme/rc
>>
>>> +
>>> +    _setup_nvmet
>>> +
>>> +    truncate -s 512M "${scratch}"
>>> +
>>> +    port="$(_create_nvmet_port "${nvme_trtype}")"
>>> +
>>> +    _create_nvmet_subsystem "${subsys}1" "${scratch}"
>>> +    _add_nvmet_subsys_to_port "${port}" "${subsys}1"
>>> +    _create_nvmet_host "${subsys}1" "${hostnqn}"
>>> +    _set_nvmet_hostkey "${hostnqn}" "${hostkey}"
>>
>> Can you comment that hash/dhgrp are used with their default values.
>>
> Sure.
> 
>>> +
>>> +    nvme connect -t "${nvme_trtype}" -n "${subsys}1" \
>>> +         -a "${def_traddr}" -s "${def_trsvcid}" -S "${hostkey}" \
>>> +         --hostnqn="${hostnqn}" --hostid="${hostid}"
>>> +
>>> +    nvme list-subsys
>>
>> Why not just look in the connect retcode? why do you need the
>> list-subsys output?
>>
> Hmm. Possibly I could; just found it more obvious the check if the
> namespace shows up in the system as expected.
> Reasoning being that it doesn't help if nvme returns no error, but
> the namespace doesn't show up.
> But I'm open to suggestions.

What does the namespace has to do with inband auth?
But if you really want to, you can still try to access
the subsystem and retrieve the hostkey and/or validate
the ns device node exist or something like that...