Performance impact with libspdm

[PrithviAPai]

Hi Team,

I went into a scenario where I see lot of performance impact when I try to send/receive data with libspdm. The transaction happens over MCTP.

Scenario:

1. We have multiple upper layer application like PLDM, NC-SI, NVME-MI, Applications performing vendor defined operations etc.
2. All these applications are talking to a single endpoint over MCTP.
3. Once secure session is established all the applications are supposed to transfer/receive data in encrypted manner.
4. SPDM becomes a bottleneck for 2 reasons: a) We have one buffer to send/receive which makes it difficult to send/receive parallel request/response. b) libspdm requires response for a request sent. (Doesn't support async way of transfer and receive)
5. Because of this, until a message is sent and received all the other messages will be waiting for its turn. The request will pile up in the longer run.

Thanks, Prithvi A Pai

[jyao1]

a) We have one buffer to send/receive which makes it difficult to send/receive parallel request/response.

You can use two buffer for send and receive. libspdm does not have such restriction.

b) libspdm requires response for a request sent.

That is required in SPDM spec. That is why the limitation is there in the beginning. With eventing support (https://github.com/DMTF/libspdm/issues/2287), I think it will be relaxed.

[PrithviAPai]

a) We have one buffer to send/receive which makes it difficult to send/receive parallel request/response.

You can use two buffer for send and receive. libspdm does not have such restriction.

b) libspdm requires response for a request sent.

That is required in SPDM spec. That is why the limitation is there in the beginning. With eventing support (#2287), I think it will be relaxed.

For sending app messages also do we have restrictions to get response before we send other request ? Should it be synchronous ?

[jyao1]

It depends. I think SPDM VDM has such requirement.

[jyao1]

I am not sure all other APP messages. Need review APP spec.

[steven-bellock]

Since the SPDM specification is super flexible on VDMs I believe it's legal to specify a VDM that consists only of a request and has no corresponding response.

[steven-bellock]

Also from https://github.com/DMTF/libspdm/blob/main/doc/design.md

The buffers have the following properties:

• libspdm never writes data to the receive buffer so the buffer may be read-only.
• libspdm both reads from and writes to the send buffer. Note that in a future release libspdm may never read from the send buffer, allowing it to be write-only.
• libspdm always releases the send buffer before acquiring the receive buffer and releases the receive buffer before acquiring the send buffer. Because of this the send buffer and receive buffer may overlap or be the same buffer.
• libspdm assumes that, when populating the send buffer or parsing the receive buffer, both buffers cannot be modified by external agents. It is the library Integrator's responsibility to ensure that the buffers cannot be tampered with while libspdm is accessing them.

[PrithviAPai]

Also from https://github.com/DMTF/libspdm/blob/main/doc/design.md

The buffers have the following properties:

• libspdm never writes data to the receive buffer so the buffer may be read-only.
• libspdm both reads from and writes to the send buffer. Note that in a future release libspdm may never read from the send buffer, allowing it to be write-only.
• libspdm always releases the send buffer before acquiring the receive buffer and releases the receive buffer before acquiring the send buffer. Because of this the send buffer and receive buffer may overlap or be the same buffer.
• libspdm assumes that, when populating the send buffer or parsing the receive buffer, both buffers cannot be modified by external agents. It is the library Integrator's responsibility to ensure that the buffers cannot be tampered with while libspdm is accessing them.

Okay, I will check this. Thanks a lot for pointers But it seems that, for sending and receiving APP message we should provide support from libspdm to send and receive data in async manner. The reason is in the scenario as I mentioned earlier, when we wait for response to arrive the other request keep piling. And the senderBuffer is Acquired. Hence when other request tries to acquire we have LIBSPDM_ASSERT ed

[steven-bellock]

For GPU confidential compute we (NVIDIA) establish an initial SPDM session and then use the Export Master Secret to derive lots of new symmetric keys. We then have separate buffers for each key, and only SPDM messages go through libspdm.

[PrithviAPai]

@steven-bellock @jyao1 For my use case as mentioned above. I changed the existing APIs to give me encrypted payload/decrypted payload. I performed stress test with my device as Requester and i2c simulator as SPDM Responder. SPDM emulator(https://github.com/DMTF/spdm-emu/tree/main) runs on i2c simulator. With that test, I run into following issue.

1. Application message is given to libspdm for encryption msg code 0x80 not found!!! libspdm_send_spdm_request[ffffffff] msg <unknown>(0x80), size (0x4): 0000: 01 80 00 02 smbus: >TX> 0F 42 13 01 09 08 C8 06 FF FF FF FF BD 05 34 00 11 D4 BA 97 ED 27 40 D0 1D 4D 91 4B 67 D3 5E 5E 3A ED 08 70 A8 13 B5 F8 4A 1D 92 98 17 50 77 07 DF DB 8D 88 9D 94 A1 7E 85 C8 4B A8 19 71 2B E1 38 EB 69 7F D2
2. We dont wait for response meanwhile another application request is given to libspdm for encryption msg code 0x80 not found!!! libspdm_send_spdm_request[ffffffff] msg <unknown>(0x80), size (0x4): 0000: 01 80 00 02 smbus: >TX> 0F 30 13 01 09 08 C9 06 FF FF FF FF BE 05 22 00 2E 43 F9 2C 99 85 A9 E4 BE C8 10 AE B1 1E 09 72 04 0C 29 9D 40 10 B6 FC 4E FD 2B 7D 4E 20 70 F2 30 85 8D
3. At this point we get a series of response from SPDM Emulator for previous requests sent. smbus: <RX< 12 0F 45 00 01 08 09 80 06 FF FF FF FF BD 05 38 00 D9 88 80 6A 99 87 EA 7C AB 92 46 F9 55 DC 0B 8A DE 57 E8 48 19 2E 69 26 5E 30 4D 1B 90 17 21 43 2D 40 D5 B7 BE AA 54 BF 6D 73 C2 D1 1E 51 EF F6 8C F4 3B 3D F2 DB F2 02 smbus: <RX< 12 0F 06 00 01 08 09 50 B4 BB smbus: <RX< 12 0F 2D 00 01 08 09 C1 06 FF FF FF FF BE 05 1F 00 92 A2 FF C1 D3 D8 2F 06 00 FB A4 44 75 D0 2F 95 AF 0D D2 59 01 59 26 33 B7 0F A0 A3 5B A2 34 93 libspdm_decode_secured_message - 0x80010005 libspdm_receive_spdm_response[ffffffff] app_message mismatch
4. From this point for all the response messages app_message mismatch error continues.

Questions:

1. As discussed earlier we don't have compulsion for synchronous request/response yet we see app_message mismatch error?
2. Once any response decryption fails should requester be starting session again ? or will it be able to continue to operate using same session ?