Ms abi

[Uriah-wolfSSL]

Description

Added WOLFSSL_ABI macros to the customer requested API that must not change in the future. This will allow us to track them and make sure they do not change.

Fixes zd# NA

Testing

How did you test?

Ran it through the ABI test scripts.

Checklist

• [X] added tests - TBD
• [X] updated/added doxygen - NA
• [X] updated appropriate READMEs - Yes, but more may follow
• [X] Updated manual and documentation - NA

[dgarske]

@Uriah-wolfSSL please resolve any Jenkins / ABI test issues. @ejohnstown is the expert on the ABI work.

[dgarske]

in order to add WOLFSSL_ABIs to ecc.c, at a minimum we're going to need to add allocator and deallocator functions for the ecc_key struct itself.

that's because WOLFSSL_ABI-using apps can only use WOLFSSL_ABI calls, and in particular, they need to use them exclusively to allocate and access objects that will be passed into libwolfssl.

notice that ecc_key** never appears in ecc.c -- there's no way with the current ecc.c that the caller can get the library to do the allocation for it.

the crucial thing is that if the app allocates the object itself, e.g. on the stack with struct ecc_key key0 or on the heap with struct ecc_key *key0 = (struct ecc_key *)malloc(sizeof *key0), then it's baking in the size of the struct, as of that libwolfssl version, following header files that will be superseded by later libwolfssl releases.

then if the app is linked with a new version of libwolfssl, without recompiling the app, the allocations may not match the new libwolfssl headers, and if they don't, the app will crash.

the same narrative holds for direct access to struct elements -- not allowed in a WOLFSSL_ABI application. any element access has to be through a WOLFSSL_ABI accessor routine, that imports and exports the data either as an intrinsic scalar type (int etc), or as a byte array or public struct with a structure rigidly defined and maintained in perpetuity by the WOLFSSL_ABI accessor routine.

so the next task for this PR is to carefully determine which allocators and accessors are needed but missing, and add them, WOLFSSL_ABI.

ABI ecc_key allocators already exist wc_ecc_key_new and wc_ecc_key_free. To use the ECC API's with ABI mode they must be used.

[douzzer]

yes John just pointed this out to me -- I was expecting the allocator to return an error code, not an ecc_key *.

[Uriah-wolfSSL]

It is weird that the ABI Check failed but the ABI Test passed. Anyway. I think this is why it fails. The test currently checks out wolfSSL v4.3.0-stable to use as a known past release to test against the latest code base, my branch in this case, for possible ABI changes. Release v4.3.0-stable fails to build.

src/ssl.c: In function ‘wolfSSL_X509_VERIFY_PARAM_set1_host’: src/ssl.c:23528:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation] 23528 | if (nameSz > 0) | ^~ src/ssl.c:23531:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 23531 | pParam->hostName[nameSz] = '\0'; | ^~~~~~ CC src/libwolfssl_la-tls13.lo CC wolfcrypt/test/test.o cc1: all warnings being treated as errors

If this is the cause of the failure, then it may have been failing for a while. Maybe the warning level checks were increased, or a newer version of GNU is more strict.

[Uriah-wolfSSL]

Addressed the latest reviews related to code standards and incorrect parms. The ABI test passes locally:

Comparing ABIs ... Comparing APIs ... Creating compatibility report ... Binary compatibility: 100% Source compatibility: 100% Total binary compatibility problems: 0, warnings: 0 Total source compatibility problems: 0, warnings: 0