Add initial certificate bank support and allow selecting the bank

[alistair23]

SPDM 1.4 add support for the banked architecture. Basically allowing a number of banks of certificate slots.

Currently bank support can be handled by the implementer using the CONNECTION_STATE_NEGOTIATED callback registered with libspdm_register_connection_state_callback_func().

The problem with this is it pushes a lot of complexity back to the implementer and it makes supporting the Slot Management commands tricky, as the implementer will need to handle the commands as well.

Instead let's move the bank support into libspdm. Currently we just allow at build time a 2-D array of certificates, for banks and slots. We then allow the implementation to select the bank to use, which defaults to zero.

Future patches will work on the Slot Management commands, which can then operate on specific banks.

At build time we allow users to specify their own bank count, allowing smaller bank counts on size reduced systems.

[jyao1]

SPDM 1.4 add support for the banked architecture. Basically allowing a number of banks of certificate slots.

Currently bank support can be handled by the implementer using the CONNECTION_STATE_NEGOTIATED callback registered with libspdm_register_connection_state_callback_func().

The problem with this is it pushes a lot of complexity back to the implementer and it makes supporting the Slot Management commands tricky, as the implementer will need to handle the commands as well.

Instead let's move the bank support into libspdm. Currently we just allow at build time a 2-D array of certificates, for banks and slots. We then allow the implementation to select the bank to use, which defaults to zero.

Future patches will work on the Slot Management commands, which can then operate on specific banks.

At build time we allow users to specify their own bank count, allowing smaller bank counts on size reduced systems.

I think we might want a high level design for bank management.
To me, there are too different ways:

1. Put bank management into libspdm. That means, the integrator needs to register everything to libspdm. As such, READ operation does not need to reach integrator, while WRITE operation is write-through from libspdm to the integrator's permanent configuration (e.g. NVRAM).
2. Put bank management out of libspdm. All bank management command (READ and WRITE) needs to pass-thru to integrator.

Bank management is similar to key pair info feature. Today we are using option 2) - see https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h

I feel we can start from option 2.

[alistair23]

• Put bank management out of libspdm. All bank management command (READ and WRITE) needs to pass-thru to integrator.

The issue here though is it's very complex managing the libspdm_local_context_t state in libspdm. The implementor needs to regularly update the state inside libspdm as well as handling the READ and WRITE commands.

Bank management is similar to key pair info feature. Today we are using option 2) - see https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h

I think key pairs are simpler then banks. Note that the bank approach I'm thinking about here will be similar to https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h, in that we will have to call to the implementer for handling the commands. The main difference is that libspdm understands the banks as well, compared to currently where libspdm doesn't comprehend banks and the implementer has to fake it by manually swapping out the certs

[jyao1]

• Put bank management out of libspdm. All bank management command (READ and WRITE) needs to pass-thru to integrator.

The issue here though is it's very complex managing the libspdm_local_context_t state in libspdm. The implementor needs to regularly update the state inside libspdm as well as handling the READ and WRITE commands.

Bank management is similar to key pair info feature. Today we are using option 2) - see https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h

I think key pairs are simpler then banks. Note that the bank approach I'm thinking about here will be similar to https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h, in that we will have to call to the implementer for handling the commands. The main difference is that libspdm understands the banks as well, compared to currently where libspdm doesn't comprehend banks and the implementer has to fake it by manually swapping out the certs

Ok. That is fine.
But so far, I do not have a full picture on your solution. As such, I do not feel comfortable to approve and merge this partial solution, because it might not be needed if we choose a different direction. For example, if we go option 2, then we do not need to cache all bank info in local content.

Can you do a design review to compare those 2 directions?

[jyao1]

BTW: I am trying to add SLOT_MANAGEMENT feature using option 2.
I will submit patch soon.

[alistair23]

But so far, I do not have a full picture on your solution. As such, I do not feel comfortable to approve and merge this partial solution, because it might not be needed if we choose a different direction. For example, if we go option 2, then we do not need to cache all bank info in local content.

But option 2 requires a lot more duplicated work each implementer, with a greater chance of bugs in all of them.

My plan is to keep working on this, but I didn't want to spend too much time on the bank management if it wasn't going to be accepted.

Can you do a design review to compare those 2 directions?

I can, but I'm not sure what that is

[jyao1]

@alistair23
I have submitted draft #3637, which is idea for option 2.
Please take a look and feedback.