Skip to content

CAPABILITIES: Add SupportedAlgorithms #2968

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ShitalJumbad
Copy link
Contributor

fix #2279

@ShitalJumbad ShitalJumbad force-pushed the fix-2279 branch 3 times, most recently from a061ee9 to c0d1cd5 Compare January 25, 2025 03:08
Copy link
Contributor

@steven-bellock steven-bellock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still need to figure out how this information is conveyed to the Integrator.

@ShitalJumbad ShitalJumbad force-pushed the fix-2279 branch 11 times, most recently from d8be4bf to edf4eaa Compare February 13, 2025 01:06
} spdm_supported_algorithms_block_t;

/* Specification states that total Extended algorithms count is less than or equal to 20*/
#define SPDM_ALGORITHMS_MAX_NUM_EXT_ASYM_COUNT 20
Copy link
Contributor

@steven-bellock steven-bellock Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually can just use SPDM_NEGOTIATE_ALGORITHMS_MAX_NUM_STRUCT_TABLE_ALG instead of SPDM_ALGORITHMS_MAX_NUM_STRUCT_TABLE_ALG.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we need to add SPDM version number here.

The MAX counter value maybe changed in different version.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is in the older specifications but it is an equation.

ExtAsymCount + ExtHashCount + ExtAlgCount2 + ExtAlgCount3 + ExtAlgCount4 + ExtAlgCount5 <= 20

So for spdm.h there can be

/* Maximum value for the sum of ExtAsymCount + ExtHashCount + ExtAlgCount2 + ExtAlgCount3 + ExtAlgCount4 + ExtAlgCount5 */
#define SPDM_ALGORITHMS_EXT_ALG_MAX_SUM 20

but that can be a separate issue. libspdm currently does not check that, but that does not need to be in this pull request. @ShitalJumbad you can remove SPDM_ALGORITHMS_MAX_NUM_EXT_ASYM_COUNT and SPDM_ALGORITHMS_MAX_NUM_EXT_HASH_COUNT from this pull request.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filed #3019.

@ShitalJumbad ShitalJumbad force-pushed the fix-2279 branch 2 times, most recently from dc9f8ed to 1a52978 Compare June 13, 2025 22:03
@@ -177,6 +210,8 @@ typedef struct {
/* Below field is added in 1.2.*/
uint32_t data_transfer_size;
uint32_t max_spdm_msg_size;
/* Below field is added in 1.3.*/
spdm_supported_algorithms_block_t supported_algorithms;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave feedback before to remove spdm_supported_algorithms_block_t from spdm_capabilities_response_t.

You can comment this line here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your feedback and for referencing the earlier discussion.t - cbda82c#r2151455599

To summarize, I understand the concern about including spdm_supported_algorithms_block_t in spdm_capabilities_response_t, especially since it’s a variable-length structure and may be considered a special case.

However, I added it here because, based on my reading of the SPDM 1.3 specification, it seems that spdm_supported_algorithms_block_t was introduced specifically for version 1.3, and including it in the structure aligns with the spec for that version. That said, I may be wrong, so I’m just trying to understand how we make this decision.

I’m also looping in @steven-bellock to get his perspective.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't there is any requirement to add anything defined in the spec.
If a structure is variable size, then it is OK to comment it here.

I prefer to not include it for convenience.

@@ -129,10 +129,37 @@ libspdm_return_t libspdm_get_version(libspdm_context_t *spdm_context,
uint8_t *version_number_entry_count,
spdm_version_number_t *version_number_entry);

#define LIBSPDM_MAX_EXT_ALG_COUNT 5
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libspdm does not support ext_alg. I think we can ignore them totally.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't suggest to keep the complexity.

As we already said, libspdm does not support ext_alg.
What is the value to return ext_alg to the integrator?
The integrator cannot use ext_algo with libspdm anyway.

libspdm_return_t libspdm_get_supported_algorithms(void *spdm_context,
size_t *responder_supported_algorithms_length,
void *responder_supported_algorithms_buffer,
uint8_t *spdm_version);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you include spdm_version to libspdm_responder_supported_algorithms_13_t, then you can remove spdm_version parameter here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then you can remove spdm_version parameter here.

The Integrator still needs to know what libspdm_responder_supported_algorithms_*_t to apply to responder_supported_algorithms_buffer. Without this parameter they would need to libspdm_get_data LIBSPDM_DATA_SPDM_VERSION, which is not the end of the world, but this makes it more convenient.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion! I think having the spdm_version parameter improves the convenience and usability of the API. Let me know if you have a strong preference here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can guarantee that spdm_version is already the first byte of responder_supported_algorithms_buffer, then the integrator can just check the first byte.

Or we can define following libspdm_responder_supported_algorithms_common_header structure to ensure that every libspdm_responder_supported_algorithms_13_t or libspdm_responder_supported_algorithms_14_t will use the same common header.

typedef struct {
    uint8_t spdm_version;
    /* the rest of the field is spdm_version specific */
} libspdm_responder_supported_algorithms_common_header;

I really cannot see the need to have uint8_t *spdm_version

@ShitalJumbad ShitalJumbad force-pushed the fix-2279 branch 4 times, most recently from b2ceb49 to 16488b0 Compare July 2, 2025 01:25
@ShitalJumbad ShitalJumbad marked this pull request as draft July 2, 2025 01:29
@ShitalJumbad ShitalJumbad force-pushed the fix-2279 branch 4 times, most recently from d5d8e89 to 9e0ae18 Compare July 3, 2025 20:37
fix DMTF#2279

Signed-off-by: Shital Jumbad <sjumbad@nvidia.com>
@@ -382,6 +423,61 @@ static libspdm_return_t libspdm_try_get_capabilities(libspdm_context_t *spdm_con
spdm_context->connection_info.capability.max_spdm_msg_size = 0;
}

/* Copy algorithms if requested and received */
if (get_supported_algorithms && supported_algs != NULL &&
spdm_response->header.spdm_version >= SPDM_MESSAGE_VERSION_13 &&
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using >= SPDM_MESSAGE_VERSION_13 here, should I use == SPDM_MESSAGE_VERSION_13 since I am typecasting to libspdm_responder_supported_algorithms_13_t on line 436?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good question!

I think it is OK to use >= now.
If change is needed for new version, we need to update the code anyway.

@ShitalJumbad ShitalJumbad marked this pull request as ready for review July 3, 2025 23:10

*supported_algs_length = sizeof(libspdm_responder_supported_algorithms_13_t);
dst->spdm_version = spdm_response->header.spdm_version;
dst->struct_table_count = src->param1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to check if this param1 exceeds the allowed struct_table_count.
Otherwise, it may cause buffer overflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SPDM 1.3] CAPABILITIES: Add SupportedAlgorithms
4 participants