LIBSPDM_MAX_MESSAGE_VCA_BUFFER_SIZE seems to need larger size.

[IamSukwonKim]

LIBSPDM_MAX_MESSAGE_VCA_BUFFER_SIZE is defined based on a below statement.

Length of the entire request message, in bytes. Length shall be less than or equal to 128 bytes. - Paragraph 252, Table 15 - NEGOTIATE_ALGORITHMS request message format, DSP0274_1.2.1

libspdm/include/library/spdm_common_lib.h

Lines 212 to 224 in f5e8613

	/*
	* +--------------------------+------------------------------------------+---------+
	* | GET_VERSION | 4 | 1 |
	* | VERSION {1.0, 1.1, 1.2} | 6 + 2 * 3 = 12 | 1 |
	* +--------------------------+------------------------------------------+---------+
	* | GET_CAPABILITIES 1.2 | 20 | 1 |
	* | CAPABILITIES 1.2 | 20 | 1 |
	* +--------------------------+------------------------------------------+---------+
	* | NEGOTIATE_ALGORITHMS 1.2 | 32 + 4 * 4 = 48 | 2 |
	* | ALGORITHMS 1.2 | 36 + 4 * 4 = 52 | 2 |
	* +--------------------------+------------------------------------------+---------+
	*/
	#define LIBSPDM_MAX_MESSAGE_VCA_BUFFER_SIZE (150 + 2 * LIBSPDM_MAX_VERSION_COUNT)

This value assumes that there are no ExtAsymCount and no ExtHashCount. However, in point of responder's view, It doesn't know how long the NEGOTIATION_ALGORITHMS will be until receive it. So, It would be better to allocate additional 80 bytes to reserve Maximum length, 128 bytes.

And also, It can be required additional space for fields which include ExtAsymSel, ExtHashSel and each AlgExternal for ALGORITHMS. However, we can remain these for configurable value, in my opinion.

[jyao1]

@IamSukwonKim, this is valid point. Thanks!

So far, we do not see any Ext use case, and libspdm does not support Ext algorithm at all.

Would you please share with us what use case you will have to support Ext Algorithm?

[IamSukwonKim]

@jyao1, It’s my pleasure. Thank you :)

Would you please share with us what use case you will have to support Ext Algorithm?

We don' have any use cases for Ext. Algorithm, too. What I'm trying to say is that the responder can't be sure that there will be no Ext Algorithm in the future, because of the specification.

So far, we do not see any Ext use case, and libspdm does not support Ext algorithm at all.

If there are no use case, why don't we get rid of the fields. So, that we can save memory.

[steven-bellock]

Even if an endpoint does not support the ext algorithms they'll still end up in the transcript. The memory allocation for VCA should reflect that, within reason.

[IamSukwonKim]

Even if an endpoint does not support the ext algorithms they'll still end up in the transcript. The memory allocation for VCA should reflect that, within reason.

Of course, if we're sure by considering backward compatibility, code complexity or something else, we might remove it from the spec. first, and then from the code.

[jyao1]

@IamSukwonKim, can we assign to you, then you can propose a patch?

[IamSukwonKim]

@IamSukwonKim, can we assign to you, then you can propose a patch?

First, PR is not possible in my work environment. Second, I'm not sure if I'm allowed to PR outside of my workspace, and third, even if I could, it would take a long time because I'm so busy these days.

I want to do the work. If I find out a way, I'll let you know again.