-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
transport: storage: add support for SPDM over the storage binding (DSP0286) #2827
base: main
Are you sure you want to change the base?
Conversation
8ab52c6
to
7a14888
Compare
A couple of high level comments.
|
7a14888
to
c63269b
Compare
Yeah that sounds good, just wanted to get comments early on
I've updated the license header with an author tag, is that sufficient? Diff: https://github.com/DMTF/libspdm/compare/7a14888587717c8a16e7390388fd39629e7a7076..c63269b162af091a35ef282052980087a378c68f |
Presumably authorship is recorded in the commit log, but if you want to put it in the file itself:
|
include/industry_standard/storage.h
Outdated
typedef struct { | ||
uint16_t data_length; | ||
uint16_t storage_binding_version; | ||
uint8_t max_connection_id : 2; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The codebase avoids bitfields due to ambiguities in the C specification. The current specification calls this Byte4
which should probably be changed to something more descriptive. See https://github.com/DMTF/SPDM-WG/issues/3621.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay sounds good, do we want to wait on this until the spec is updated then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we'll probably discuss this issue at the VF2F meeting today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right. Using bitfield is not recommended.
I recommend you just using uint8_t max_connection_id
, then use bitmask MACRO, such as SPDM_STORAGE_MAX_CONNECTION_ID_MASK 0x3
to get the value.
include/industry_standard/storage.h
Outdated
uint16_t storage_binding_version; | ||
uint8_t max_connection_id : 2; | ||
uint8_t _reserved1[3]; | ||
uint8_t supported_operations[8]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be one byte in the specification if https://github.com/DMTF/SPDM-WG/issues/3609 gets approved.
include/industry_standard/storage.h
Outdated
#define STORAGE_OPERATION_CODE_MESSAGE 0x05 | ||
#define STORAGE_OPERATION_CODE_SECURED_MESSAGE 0x06 | ||
|
||
#define STORAGE_MAX_SIZE_IN_BYTE 0x00100000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is defined or inferred from the specification?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not from the spec, we used the DoE transport for layer as a reference for this.
#define PCI_DOE_MAX_SIZE_IN_BYTE 0x00100000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PCIe specification explicitly defines those values. If they are not in DSP0286 or an underlying specification then they should be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right. only SPDM storage binding spec defined data should be here.
Any other implementation definition should NOT be added here.
return LIBSPDM_STATUS_INVALID_MSG_FIELD; | ||
} | ||
|
||
#if CMAKE_C_BYTE_ORDER == LITTLE_ENDIAN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SPDM message fields (and libspdm) are all little-endian. Is there a big-endian field coming from the underlying storage technology?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was to be consistent with the byte ordering defined in the SCSI Primary Commands specification (SPC) where BE is used for the command blocks. The SPC is referred to by the NVMe spec for the Security In/Out implementation also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For context in qemu
, we will generate the header as such: https://github.com/twilfredo/qemu/blob/d40afa3ad43417d01cf7a6e758a434e3858d0200/hw/nvme/ctrl.c#L7124
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So NVMe / SCSI use BE. What about ATA?
@bhenning10 the specification should probably have a statement on endianness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ATA Spec specifies the trusted send/recv
commands to be a 28bit command block in LE. Since this is a virtual header (libspdm
specific) we are parsing here, would it be best to use LE to stay consistent with SPDM message fields? What do we think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@twilfredo we can discuss that in https://github.com/DMTF/SPDM-WG/issues/3625.
e50ff9f
to
8fc10b2
Compare
#include "hal/library/debuglib.h" | ||
#include "hal/library/memlib.h" | ||
|
||
# define BSWAP32(x) ((((x) & 0x000000ff) << 24) | \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libspdm/include/internal/libspdm_common_lib.h
Line 1705 in b327ead
static inline uint64_t libspdm_le_to_be_64(uint64_t value) |
libspdm_byte_swap_*
and place them there. libspdm_le_to_be_64
can be renamed to libspdm_byte_swap_64
in a subsequent pull request to make things consistent.
Usually, the implementation for WIP should NOT be posted to main, but a WIP specific branch The WIP branch can be merged into main, after the WIP spec becomes official standard. |
Okay noted, are you happy to keep this up for now? since review is in progress. |
That is fine. We can keep reviewing and address all feedback in this PR. Whenever you think it is done and ready for merge, you can switch to branch merge request. |
* Alistair Francis <alistair.francis@wdc.com> | ||
**/ | ||
|
||
#include "library/spdm_transport_storage_lib.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have any unit test associated to prove the correctness of this function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't written any explicit test cases for all the functions in this files. We have tested the logic by testing with QEMU + spdm-utils
+ linux (Kernel SPDM) though. I'm waiting for the spec to become ratified so we can add some of the changes discussed above.
I can add some tests if they are required? Are there exists tests for other transports?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, we will need two level of test:
- Unit test in libspdm project.
- System test in spdm-emu project.
In history, both tests can catch some error.
Please consider to add both.
5a5ce6f
to
7d5dfea
Compare
As defined by DSP0826, add support for SPDM storage transport. The transport layer uses a virtual storage header that encapsulates SPDM requests to allow the caller to generate the required parameters for a storage SPDM request. SPDM responses are not transport encoded, with this header, instead just the message is returned. Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
This allows transports such as Storage (DSP0286) to determine if the next response is protected via secured messages. Unlike other transport layers, storage does not encode the message type in a response header. As such, the requester must track the expected type. The issue [1] discusses this implementation requirement in further detail with regards to DSP0286. [1] DMTF/SPDM-WG#3520 Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
7d5dfea
to
5569c6c
Compare
@twilfredo , do you want to keep it in PR? or do you want to push to a branch, and keep updating the branch? I am OK either way. But I just feel a branch might be more helpful. |
I'll stick to the PR is that's okay with everyone. I'm just waiting for the spec to be ratified so I can address all the changes in one go. |
This series adds
libspdm
transport support for SPDM over Storage Binding Specification [1]. This allows for example NVMe or SCSI devices that conform to [1] to communicate with a host requester using the storage transport medium as defined in [1].[1] https://www.dmtf.org/sites/default/files/standards/documents/DSP0286_1.0.0WIP90.pdf