Current libspdm architecture

Current architecture of libspdm requires providing callback functions for sending and receiving messages (see libspdm_register_device_io_func ). Such approach is sufficient for a client application that calls libspdm library, because the client application is the "caller" (or "initiator") of the SPDM flow.

New business case

There is a different business use case, where it is the cloud service (for example REST API service) that is using libspdm but the "caller" (or "initiator") of the flow is a network client calling REST API.

Problem statement

At least three problems arise in such situation:

1. The REST API service must keep the SPDM connection alive on a thread while waiting for a client to provide response to SPDM message - the service is no longer stateless,
2. The REST API service must ensure a separate SPDM connection thread for each client,
3. The REST API service cannot be run in classic microservice architecture in multiple instances (e.g. behind a load balancer), because an additional external mechanism of synchronization of libspdm threads between service instances must be implemented.

Proposed solution

Proposed solution to all of those problems is splitting the existing APIs, like libspdm_get_version, libspdm_get_measurement, etc. to separately invoke sending message and handling received response, but maintaining backward compatibility to existing implementation, i.e.:

libspdm_return_t libspdm_get_measurement(...) {
    char output_buffer[...];
    char input_buffer[...];
    libspdm_get_measurement_send_message(..., output_buffer);
    libspdm_device_send_message_func(output_buffer);
    libspdm_device_receive_message_func(input_buffer);
    libspdm_get_measurement_handle_response(..., input_buffer);
}

In this way, current implementors would still call one method libspdm_get_measurement(...) which would perform both send message and handle response, but at the same time allowing to call libspdm_get_measurement_send_message separately from libspdm_get_measurement_handle_response.

This would enable multiple instances of REST API service to share SPDM connection only by sharing SPDM context.

All slides explaining the problem and solution can be found in the attached presentation:
libspdm_SPDM_API_split_proposal.pdf