Slot Management — Relational Data Model Proposal

[jyao1]

[Background]
SPDM 1.4 added slot management feature (#3131).

[Problem Statement]
When we are trying to add slot management (#3637), we realize the there are problem of inconsistency in current cert and key_pair management. For example,

• SetCert is NOT synced to local context yet. [SET_CERTIFICATE] Save certificate into SPDM context #873
• assoc_cert_slot_mask not consistent with slot certs or DIGESTS per-slot KeyPairID. In device sample, assoc_cert_slot_mask not consistent with slot certs or DIGESTS per-slot KeyPairID #3638
• SlotState is not fully supported. No path produces the "Exists with key" slot state #3645

https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management.md summarized the current status and add slot_management API on top of it. But the gap/limitation is still there.

[Proposal]
In order to fully resolve the inconsistency issue, we need a better way to management the bank/slot/key_pair/algo/cert, etc.

https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md is the proposal.

[alistair23]

I tried to read https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md, but it's very verbose and hard to follow (then I realised it was partially written by an AI).

My understanding from https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md#schema-c-structures is that this approach is basically a 3D array or certs/keys, not dissimilar to the direction #3629 is going in.

It's a simple 3D array in C. Easy to manage and understand. Overall the idea is fine with me, although I'm not sure about the exact structure. I would prefer a single array maybe

typedef struct {
    libspdm_db_key_pair_t       key_pair[LIBSPDM_DB_MAX_KEY_PAIRS];
    libspdm_db_bank_t           bank;
    libspdm_db_slot_t           slot[LIBSPDM_DB_MAX_SLOTS];
    libspdm_db_slot_key_assoc_t slot_key_assoc[LIBSPDM_DB_MAX_SLOTS];
    libspdm_db_cert_chain_t     cert_chain[LIBSPDM_DB_MAX_SLOTS];
    libspdm_db_csr_t            csr[LIBSPDM_DB_MAX_SLOTS];
    ...
} libspdm_bank_t;

and then

libspdm_bank_t banks[LIBSPDM_DB_MAX_BANKS]

Another idea I just had is to support an actual database. We wouldn't do this in libspdm, but instead have library helper functions that implementations have to use. That would for example require functions like add_cert(slot, bank, alg) and get_cert(slot, bank, alg) to be implemented by the implementation. Then libspdm would never actually store the certchain/keys and would just load it on the fly. The big advantage here is then the implementation can use a database fit for their application. So an embedded application can just read/write directly to their flash database, while a full blown PC could use sqlite. It also means there is only ever one truth and everything else queries from there

[jyao1]

First, thanks to feedback.

My understanding from https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md#schema-c-structures is that this approach is basically a 3D array or certs/keys, not dissimilar to the direction #3629 is going in.
It's a simple 3D array in C. Easy to manage and understand.

If I could make it simple, I would.

But unfortunately, it is NOT 3D array according to SPDM spec. Bank management and KeyPair management are 2 different API set.
If we make key_pair to be part of bank, then changing bank algo will impact key_pair. That is not expected.

Another idea I just had is to support an actual database. We wouldn't do this in libspdm, but instead have library helper functions that implementations have to use. That would for example require functions like add_cert(slot, bank, alg) and get_cert(slot, bank, alg) to be implemented by the implementation. Then libspdm would never actually store the certchain/keys and would just load it on the fly. The big advantage here is then the implementation can use a database fit for their application. So an embedded application can just read/write directly to their flash database, while a full blown PC could use sqlite. It also means there is only ever one truth and everything else queries from there

Right. I do not want to expose the database in libspdm.
My intension is to use passthru API in libspdm, (like what I have proposed), and let device sample use the database.
The database design is only a reference design in OS stub. The API help function can be invoked by the device sample, but not libspdm.
That will give flexibility to integrator on if they want to implement the bank/slot/key_pair/keys.

At least in 4.0, I think we do not have time to do such a big change.

[alistair23]

But unfortunately, it is NOT 3D array according to SPDM spec. Bank management and KeyPair management are 2 different API set. If we make key_pair to be part of bank, then changing bank algo will impact key_pair. That is not expected.

First, just to clarify, when I say 3D array, I actually mean 2D array (off by one). It's a square (x and y axis) not a cube.

What makes you think KeyPair is not part of the bank? Looking at Table 144 — GetCSR structure format I see that the requester specifies a BankID and then a KeyPairID. To me it looks like KeyPair is part of a bank.

My intension is to use passthru API in libspdm, (like what I have proposed), and let device sample use the database.

I don't think we should expose the libspdm_db_t to implementations. It should stay internal, otherwise it will be a nightmare to update or change in the future.

Plus it's very prescriptive for implementations. That's a lot to keep in memory for small embedded systems for example.

The database design is only a reference design in OS stub. The API help function can be invoked by the device sample, but not libspdm.

I don't follow. You have defined libspdm_db_t for libspdm to use, but then it doesn't use it?

[jyao1]

What makes you think KeyPair is not part of the bank? Looking at Table 144 — GetCSR structure format I see that the requester specifies a BankID and then a KeyPairID. To me it looks like KeyPair is part of a bank.

In general, I do not think KeyPairID is part of Bank, because the SPDM specification did not say that.
Looking at the query API in slot_management API, BankDetails even returns a duplicated structure (CurrentAsym and CurrentAsymCapability) with KeyPairInfo. (But they are different).
If KeyPairID should be part of Bank, then BankDetails should just return KeyPairID, not duplicated structure.
Anyway, if you still have doubt, I will file an issue and ask SPDM WG.

I don't follow. You have defined libspdm_db_t for libspdm to use, but then it doesn't use it?

I mean, libspdm core library does not use libspdm_db_t. It is device sample uses it instead.
As you see it is a very complicated. It is integrator's choice on how to do that for a device.
If a device is so simple that do not have part of feature (CSR, SET_CERT, SLOT_MANAGEMENT, KEY_PARI_INFO), then there is no need to use the libspdm_db_t. Or it can use a simpler one.

All in all, I do not want to enforce this full database design for a device. The device can make choice for different consideration.
That is the primary reason I defined pass-thru HAL API, just follow SPDM spec.

[alistair23]

In general, I do not think KeyPairID is part of Bank, because the SPDM specification did not say that. Looking at the query API in slot_management API, BankDetails even returns a duplicated structure (CurrentAsym and CurrentAsymCapability) with KeyPairInfo. (But they are different). If KeyPairID should be part of Bank, then BankDetails should just return KeyPairID, not duplicated structure. Anyway, if you still have doubt, I will file an issue and ask SPDM WG.

I have filed an issue: https://github.com/DMTF/SPDM-WG/issues/4560

What I read is this

"""
148: An SPDM endpoint can use more than one asymmetric key pair for a negotiated asymmetric algorithm.
150: To facilitate the use of multiple asymmetric keys, the ability to uniquely identify each key pair is essential. To achieve
this, a unique key pair number, called KeyPairID , identifies each asymmetric key pair. Additionally, one or more leaf
certificates can bind to the same asymmetric key pair.
"""

Then Table 41 — Successful DIGESTS response message format defines KeyPairID[n-1 as "the KeyPairID of the key pair associated with CertSlot[n-1]", so assigned to a certificate slot.

Then:

"""
988: If a device implementation supports multiple asymmetric algorithms, it only presents slots that match the negotiated
algorithm, whether those slots are populated or vacant. The management of such a scheme could use multiple setsof slots, which are logically grouped into Banks. A Bank has a set of properties, including an asymmetric algorithm
that is used for all slots in the Bank. For instance, a device might have three Banks of slots which allow it to support
three different asymmetric algorithms, and when an asymmetric algorithm is negotiated, the device would activate
the correct Bank of slots. Conceptually, the Responder uses the asymmetric algorithm that is selected during
algorithm negotiation to select a Bank. Commands like GET_CERTIFICATE and CHALLENGE operate on the slots in the
Bank that is selected during the algorithm negotiation.
"""

Which sounds like KeyPair works inside each bank

I mean, libspdm core library does not use libspdm_db_t. It is device sample uses it instead.

But then how does the example propagate? You say:

SET_CERTIFICATE(bank=0, slot=1, chain C, model=DeviceCert) with no reset required:

/* ensure the slot exists and is associated to a key pair of the bank's algorithm, then install */
db->slot[0][1].present = true;                          /* slot exists (state >= 2) */
/* slot_key_assoc[0][1] must already exist, or be created via libspdm_db_associate_slot_key() */
db->cert_chain[0][1].present          = true;           /* provisioned (state 4) */
db->cert_chain[0][1].certificate_info = SPDM_CERTIFICATE_INFO_CERT_MODEL_DEVICE_CERT;
db->cert_chain[0][1].der_size         = C_size;
libspdm_copy_mem(db->cert_chain[0][1].der, sizeof(db->cert_chain[0][1].der), C, C_size);

"Immediately afterwards, without any extra code in the other command handlers:
GET_CERTIFICATE(slot=1) (if bank 0 is the selected bank) returns C — reads cert_chain[0][1]."

How does libspdm know about the new certificate chain?

The Access API also uses libspdm_db_t. If libspdm isn't using libspdm_db_t what is calling those APIs?

I am very confused 😕

All in all, I do not want to enforce this full database design for a device. The device can make choice for different consideration. That is the primary reason I defined pass-thru HAL API, just follow SPDM spec.

Which pass-thru HAL API?

[jyao1]

I have filed an issue: https://github.com/DMTF/SPDM-WG/issues/4560

Great. Let's discuss that later.
I also put a libspdm gating label there to make sure it is discussed in next meeting.

Which pass-thru HAL API?

The slot_management APIs, which I proposed at #3637. (See https://github.com/jyao1/libspdm/blob/slot_management/include/hal/library/responder/slot_mgmt.h)
Plus csr/set_cert/key_pair HAL APIs which we have today. (See https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/csrlib.h, https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/setcertlib.h, https://github.com/DMTF/libspdm/blob/main/include/hal/library/responder/key_pair_info.h)

In general my thought is:
libspdm responder core library -- (HAL passthru API) --> device sample -- (database access API) --> database management

The gist is that libspdm core library does not touch database directly, but treat it as an implementation choice.

[alistair23]

The slot_management APIs, which I proposed at #3637. (See https://github.com/jyao1/libspdm/blob/slot_management/include/hal/library/responder/slot_mgmt.h)

Oh! I thought https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md was instead of #3637. That is not clear. The fact that all of the structs are libspdm_* make it even less clear

I don't see how https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md fixes the sync issues in #3637 though. libspdm still has it's internal cert chain that will be out of sync. You will need to remove that from libspdm and delegate all database accesses to the device sample, like I mentioned here: #3646 (comment). But that isn't mentioned in the proposal.

[jyao1]

I don't see how https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md fixes the sync issues in #3637 though. libspdm still has it's internal cert chain that will be out of sync.

You are right that a database does not fix the internal cert chain sync issue. More code is required in sample driver to sync the database and libspdm contenxt.

I would like to clarify couple of thing:

1. The sync issue is NOT introduced by add Slot management #3637. The sync issue was there since [SET_CERTIFICATE] Save certificate into SPDM context #873.
2. The sync issue is NOT in libspdm. The sync issue was in device sample, as we already discussed in [SET_CERTIFICATE] Save certificate into SPDM context #873.

Let me restate my position:
The purpose of #3637 is to add a new feature (slot_management) in SPDM 1.4. There is not a solution to resolve all previous existing libspdm issues (including this old syncing issue).
I have no ambition to use one PR to resolve all problems. Let's set right expectation here.

Another thing I would like to clarify:
I have no plan to add the full implementation of https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md to #3637. That will be the next step on how to improve the device sample internal.

I put it to there currently, just because I want to demonstrate a full design as part of design review.

On the other hand, if you think #873 is very important, and we should fix it soon. Please step forward and propose a patch.
All in all, I think this sync issue is irrelevant to slot_management with multiple bank support. It has been there since 2022.

[alistair23]

1. add Slot management #3637 does make the sync issue worse. SET_CERTIFICATE probably also has sync issues, you can work around that if you require a reset, which I suspect is what everyone is doing. add Slot management #3637 just makes more sync issues!
2. I get your point that it's not in the libspdm library, but the design of libspdm makes it difficult to impossible to keep them in sync. Plus device sample is the reference implementation for libspdm (and is included in the libspdm code base), so it basically is in libspdm

The purpose of #3637 is to add a new feature (slot_management) in SPDM 1.4. There is not a solution to resolve all previous existing libspdm issues (including this old syncing issue).

Agreed. But #3637 adds more sync issues. As it currently stands #3637 can't actually be used by an implementation correctly. The reference device sample doesn't work correctly, which is a sign that #3637 should not be merged as it is. Let's not dig a bigger hole!

I have no ambition to use one PR to resolve all problems. Let's set right expectation here.

Of course not. Let's just not make things worse

I have no plan to add the full implementation of https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md to #3637. That will be the next step on how to improve the device sample internal.

https://github.com/jyao1/libspdm/blob/slot_management/doc/slot_management_database.md does not address the sync issues with #3637, so as it stands #3637 still isn't workable.

On the other hand, if you think #873 is very important, and we should fix it soon. Please step forward and propose a patch.
All in all, I think this sync issue is irrelevant to slot_management with multiple bank support. It has been there since 2022.

Patches are proposed! #3629 is a step in that direction

[alistair23]

#3658 should resolve #873, which fixes the sync issues with current upstream