-
Notifications
You must be signed in to change notification settings - Fork 123
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
base: main
Are you sure you want to change the base?
Conversation
a061ee9
to
c0d1cd5
Compare
There was a problem hiding this 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.
d8be4bf
to
edf4eaa
Compare
b1dc2d7
to
da7747c
Compare
include/industry_standard/spdm.h
Outdated
} 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 |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #3019.
dc9f8ed
to
1a52978
Compare
@@ -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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #2968 (comment).
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
b2ceb49
to
16488b0
Compare
d5d8e89
to
9e0ae18
Compare
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 && |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
||
*supported_algs_length = sizeof(libspdm_responder_supported_algorithms_13_t); | ||
dst->spdm_version = spdm_response->header.spdm_version; | ||
dst->struct_table_count = src->param1; |
There was a problem hiding this comment.
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.
fix #2279