Re: [PATCH] [RFC] cryptodev: replace LIST_END enumerators with APIs

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 9/5/2024 11:14 AM, Akhil Goyal wrote:
> Replace *_LIST_END enumerators from asymmetric crypto
> lib to avoid ABI breakage for every new addition in
> enums with inline APIs.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> This patch was discussed in ML long time back.
> https://patches.dpdk.org/project/dpdk/patch/20211008204516.3497060-1-gakhil@marvell.com/
> Now added inline APIs for getting the list end which need to be updated
> for each new entry to the enum. This shall help in avoiding ABI break
> for adding new algo.
> 

Hi Akhil,

*I think* this hides the problem instead of fixing it, and this may be
partially because of the tooling (libabigail) limitation.

This patch prevents the libabigail warning, true, but it doesn't improve
anything from the application's perspective.
Before or after this patch, application knows a fixed value as END value.

Not all changes in the END (MAX) enum values cause ABI break, but tool
warns on all, that is why I think this may be tooling limitation [1].
(Just to stress, I am NOT talking about regular enum values change, I am
talking about only END (MAX) value changes caused by appending new enum
items.)

As far as I can see (please Dodji, David correct me if I am wrong) ABI
break only happens if application and library exchange enum values in
the API (directly or within a struct).

Exchanging enum values via API cause ABI issues because:
1. enum size is not fixed, it uses min storage size that can hold all
values, adding new enums may cause its size change and of course this
breaks ABI.
2. Library can send enum values that application doesn't know, this may
cause application behave undefined.
3. Application sending MAX value (or more) to API expects error, but
that may be a valid value in the new library and applications gets
unexpected result.


Let's assume above 1. happens, with this patch warning is prevented, but
ABI break still can occur.

One option can be not exchanging enums in APIs at all, this way changes
in the END (MAX) enum values are harmless. But I can see cryptodev does
this a lot.

When enum is exchanged in APIs, and if we want to be strict about the
ABI, safest option can be not appending to enums at all, and keeping END
(MAX) items can be a way to enable warnings for this.


More relaxed option is protect against only 1. since that is the real
ABI issue, 2 & 3 are more defensive programming, so as long as enum size
is not changed we may ignore the END (MAX) value change warnings.



[1] It would be better if tool gives END (MAX) enum value warnings only
if it is exchanged in an API, but not sure if this can be possible to
detect.


>  app/test/test_cryptodev_asym.c  |  2 +-
>  lib/cryptodev/rte_crypto_asym.h | 18 ++++++++++++++----
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index f0b5d38543..f1ece475b8 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -581,7 +581,7 @@ static inline void print_asym_capa(
>  			rte_cryptodev_asym_get_xform_string(capa->xform_type));
>  	printf("operation supported -");
>  
> -	for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> +	for (i = 0; i < rte_crypto_asym_op_list_end(); i++) {
>  		/* check supported operations */
>  		if (rte_cryptodev_asym_xform_capability_check_optype(capa, i)) {
>  			if (capa->xform_type == RTE_CRYPTO_ASYM_XFORM_DH)
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 39d3da3952..290b300f84 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -72,6 +72,7 @@ enum rte_crypto_curve_id {
>   * Asymmetric crypto transformation types.
>   * Each xform type maps to one asymmetric algorithm
>   * performing specific operation
> + * Note: Update rte_crypto_asym_xform_type_list_end() for every new type added.
>   */
>  enum rte_crypto_asym_xform_type {
>  	RTE_CRYPTO_ASYM_XFORM_UNSPECIFIED = 0,
> @@ -119,12 +120,17 @@ enum rte_crypto_asym_xform_type {
>  	 * Performs Encrypt, Decrypt, Sign and Verify.
>  	 * Refer to rte_crypto_asym_op_type.
>  	 */
> -	RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> -	/**< End of list */
>  };
>  
> +static inline int
> +rte_crypto_asym_xform_type_list_end(void)
> +{
> +	return RTE_CRYPTO_ASYM_XFORM_SM2 + 1;
> +}
> +
>  /**
>   * Asymmetric crypto operation type variants
> + * Note: Update rte_crypto_asym_op_list_end for every new type added.
>   */
>  enum rte_crypto_asym_op_type {
>  	RTE_CRYPTO_ASYM_OP_ENCRYPT,
> @@ -135,9 +141,14 @@ enum rte_crypto_asym_op_type {
>  	/**< Signature Generation operation */
>  	RTE_CRYPTO_ASYM_OP_VERIFY,
>  	/**< Signature Verification operation */
> -	RTE_CRYPTO_ASYM_OP_LIST_END
>  };
>  
> +static inline int
> +rte_crypto_asym_op_list_end(void)
> +{
> +	return RTE_CRYPTO_ASYM_OP_VERIFY + 1;
> +}
> +
>  /**
>   * Asymmetric crypto key exchange operation type
>   */
> @@ -168,7 +179,6 @@ enum rte_crypto_rsa_padding_type {
>  	/**< RSA PKCS#1 OAEP padding scheme */
>  	RTE_CRYPTO_RSA_PADDING_PSS,
>  	/**< RSA PKCS#1 PSS padding scheme */
> -	RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
>  };
>  
>  /**