transport: spdm-storage: add support

[twilfredo]

As per DMTF DSP0286 (pending ratification), this series adds supports to spdm-utils to communicate spdm with nvme devices over the respective security commands.

[twilfredo]

@alistair23, note: CI won't work until upstream libspdm has storage support. So let's keep this blocked till then.

[twilfredo]

todo:

1. DMTF DSP0286 Ratification
2. libspdm storage transport support upstream
3. qemu nvme responder socket support upstream

side-quests:

1. kernel spdm && spdm-storage support upstream

[twilfredo]

@alistair23 this patch has README instructions for tcmu-runner, should we remove those?

[alistair23]

Note: CI failure is for tock-responder seems unrelated to this

error[E0599]: no variant or associated item named `Storage` found for enum `TransportLayer` in the current scope
   --> /home/runner/work/spdm-utils/spdm-utils/src/libspdm/spdm.rs:511:25
    |
286 | pub enum TransportLayer {
    | ----------------------- variant or associated item `Storage` not found for this enum
...
511 |         TransportLayer::Storage => {
    |                         ^^^^^^^ variant or associated item not found in `TransportLayer`

Seems very related

[alistair23]

@alistair23 this patch has README instructions for tcmu-runner, should we remove those?

Yeah, I think so. Also if possible it might be worth splitting the NVMe and SCSI parts out. It'll help make the PR smaller

[twilfredo]

Note: CI failure is for tock-responder seems unrelated to this

error[E0599]: no variant or associated item named `Storage` found for enum `TransportLayer` in the current scope
   --> /home/runner/work/spdm-utils/spdm-utils/src/libspdm/spdm.rs:511:25
    |
286 | pub enum TransportLayer {
    | ----------------------- variant or associated item `Storage` not found for this enum
...
511 |         TransportLayer::Storage => {
    |                         ^^^^^^^ variant or associated item not found in `TransportLayer`

Seems very related

Yeah! I deleted that comment after I fixed it.. you got to it before haha my bad

[twilfredo]

This PR now only adds the userspace side for NVMe only. SCSI and QEMU server to follow.

[twilfredo]

@alistair23 ping

[twilfredo]

@alistair23 ping

[twilfredo]

ping @alistair23 :)

[alistair23]

Why is this NULL? Especially when the size isn't 0

[twilfredo]

libspdm sets the transport_message by walking back the number of transport header bytes from message. But before doing that it needs to assert the length (so that we don't walk back into invalid memory). So transport_message_len cannot be zero currently. See below (transport_message_len is transport_message_size in libspdm.

    if (*transport_message_size < message_size + sizeof(libspdm_storage_transport_virtual_header_t)) {
        *transport_message_size = message_size + sizeof(libspdm_storage_transport_virtual_header_t);
        return LIBSPDM_STATUS_BUFFER_TOO_SMALL;
    }

This function libspdm_transport_storage_encode_message exists to extract the storage header that is added to the message so the integrator can setup the storage API calls to the device. This is a bit clunky, so we could look at improving this api later.