libspdm Verifier Support

[steven-bellock]

Problem Statement

libspdm, and possibly the Requester, does not know how to interpret device measurements or know what the expected measurement values should be. This logic typically resides in the Verifier. Ideally the Responder would sign only the Requester / Verifier provided nonce and the measurement record data, which the Requester can pass on to the Verifier. libspdm currently supports passing the nonce and the measurement records to the verifier. However the Responder signs the entire GET_MEASUREMENTS / MEASUREMENTS messages, and for SPDM 1.2 it also includes the VCA messages. libspdm does not currently support passing these messages in their entirety such that they can be consumed by the Verifier.

Proposed solution

In the Requester's spdm_context add five new fields that can be removed at compile time if not needed.

void *msg_buffer;
size_t msg_buffer_max_size;
uint8_t msg_buffer_mode;
size_t msg_buffer_offset;
bool msg_buffer_full;

After initializing spdm_context the integrator allocates buffer space and sets msg_buffer, msg_buffer_max_size, and msg_buffer_mode. msg_buffer_offset will be 0 and msg_buffer_full will be false. Integrator can then send requests and receive responses. If msg_buffer_mode is set to write to the buffer then libspdm will write the requests and responses to the buffer starting at msg_buffer_offset, which it will increment. Depending on the attributes in msg_buffer_mode writing to the buffer may saturate in which case msg_buffer_full is set to true, or it may behave like a ring buffer and overwrite the lower bytes on wraparound.

msg_buffer_mode is a bitmask with the following attributes:

ENABLE : If 1 then libspdm will write to the buffer.
INCLUDE_ERROR : If 1 then libspdm will write `ERROR` responses to the buffer.
INCLUDE_CHUNK : If 1 then libspdm will write requests and responses associated with chunking to the buffer.
WRAP_MODE : If 0 then the buffer saturates, else it is wraparound.

Questions

Does this have value on the Responder's side as well? It can potentially aid in debugging.

[steven-bellock]

Note that we can't rely on the transport's request_size / response_size as that may have transport padding; ie PCIE moves data in 4-byte chunks. libspdm would need to parse the request / response to determine the actual message size.

[steven-bellock]

Should change msg_buffer_full's type to a uint8_t and call it msg_buffer_status.

[vbodired]

Problem Statement

libspdm, and possibly the Requester, does not know how to interpret device measurements or know what the expected measurement values should be. This logic typically resides in the Verifier. Ideally the Responder would sign only the Requester / Verifier provided nonce and the measurement record data, which the Requester can pass on to the Verifier. libspdm currently supports passing the nonce and the measurement records to the verifier. However the Responder signs the entire GET_MEASUREMENTS / MEASUREMENTS messages, and for SPDM 1.2 it also includes the VCA messages. libspdm does not currently support passing these messages in their entirety such that they can be consumed by the Verifier.

Proposed solution

In the Requester's spdm_context add five new fields that can be removed at compile time if not needed.

void *msg_buffer;
size_t msg_buffer_max_size;
uint8_t msg_buffer_mode;
size_t msg_buffer_offset;
bool msg_buffer_full;

After initializing spdm_context the integrator allocates buffer space and sets msg_buffer, msg_buffer_max_size, and msg_buffer_mode. msg_buffer_offset will be 0 and msg_buffer_full will be false. Integrator can then send requests and receive responses. If msg_buffer_mode is set to write to the buffer then libspdm will write the requests and responses to the buffer starting at msg_buffer_offset, which it will increment. Depending on the attributes in msg_buffer_mode writing to the buffer may saturate in which case msg_buffer_full is set to true, or it may behave like a ring buffer and overwrite the lower bytes on wraparound.

msg_buffer_mode is a bitmask with the following attributes:

ENABLE : If 1 then libspdm will write to the buffer.
INCLUDE_ERROR : If 1 then libspdm will write `ERROR` responses to the buffer.
INCLUDE_CHUNK : If 1 then libspdm will write requests and responses associated with chunking to the buffer.
WRAP_MODE : If 0 then the buffer saturates, else it is wraparound.

Questions

Does this have value on the Responder's side as well? It can potentially aid in debugging.

Here the proposed solution is looking like more of debug log enablement, that all the request & response are available in some buffere upon it's enablement. is it going to a be added for all of the SPDM commands?
Rather, for GET_MEASUREMENTS Request, Why can't we have a additional formal API that returns everything (i.e. nonce, measurements, signature) to the GET_MEASUREMENT request caller? So that, the caller can trust the response and use it for verification.

[steven-bellock]

is it going to a be added for all of the SPDM commands?

Correct, the intent is that it can be used to capture any request and response, and that the integrator has control over what requests and responses get logged.

Why can't we have a additional formal API that returns everything (i.e. nonce, measurements, signature) to the GET_MEASUREMENT request caller?

That would entail modifying most of the functions in spdm_requester_lib.h, and some integrators my not want this functionality at all, forcing them to fill out NULL parameters or create dummy variables that are discarded. Or we could add new function wrappers like libspdm_get_measurement_ex_ex and libspdm_init_connection_ex.

[vbodired]

I recommend and prefer to have an additional wrapper API like libspdm_get_measurement_ex that sends the signature as well and that helps the caller to trust the measurements received. Can we have the API added?

[vbodired]

@jyao1 can you provide your recommendation on this? We would better need a separate API that returns the whole response, depending on debug log enabling and on debug buffers doesn't sound as right design.

[jyao1]

I think we can use this to resolve #1110

[jyao1]

Some idea on the design:

libspdm_init_message_buffer (void *spdm_context, const void *message_buffer, size_t message_buffer_max_size);
libspdm_set_message_buffer_mode (void *spdm_context, libspdm_msg_buf_mode mode);
libspdm_get_message_buffer_mode (void *spdm_context, libspdm_msg_buf_mode *mode);
libspdm_get_message_buffer (void *spdm_context, void **message_buffer, size_t *message_buffer_size, bool *is_full);
libspdm_enable_message_buffer (void *spdm_context);
libspdm_disable_message_buffer (void *spdm_context);
libspdm_reset_message_buffer (void *spdm_context);

typedef uint64_t libspdm_msg_buf_mode;
#define LIBSPDM_MSG_BUF_MODE_INCLUDE_ERROR  0x1 // If 1 then libspdm will write `ERROR` responses to the buffer.
#define LIBSPDM_MSG_BUF_MODE_INCLUDE_CHUNK 0x2 // If 1 then libspdm will write requests and responses associated with chunking to the buffer.
#define LIBSPDM_MSG_BUF_MODE_WRAP 0x4 // If 0 then the buffer saturates, else it is wraparound.

[steven-bellock]

I've been using libspdm_set_data but I can also use functions.

[jyao1]

Ref: #1164