[#1823] replace malloc/calloc/strdup/free with openssl allocator

[songlingatpan]

Replaced malloc, calloc, strdup, and free with the OpenSSL memory allocator to enable the caller to customize memory allocator, addressing issue #1823. This PR does not change the existing behavior or algorithms.

[songlingatpan]

I will commit another change for copy_from_upstream.

[baentsch]

Conceptually LGTM, but CI needs to pass; please see https://github.com/open-quantum-safe/liboqs/blob/main/CONTRIBUTING.md#coding-style

[songlingatpan]

@baentsch Question: 'bike', 'frodokem', 'ntruprime' is not from upstream.
To replace malloc with OQS_MEM_malloc, where should i modify the code? Thanks
liboqs/src/kem/frodokem/kem_frodokem976shake.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/frodokem/kem_frodokem640aes.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/frodokem/kem_frodokem1344shake.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/frodokem/kem_frodokem976aes.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/frodokem/kem_frodokem1344aes.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/frodokem/kem_frodokem640shake.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/kem.h:264:OQS_API void OQS_KEM_free(OQS_KEM *kem); liboqs/src/kem/ntruprime/kem_ntruprime_sntrup761.c:11: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/kem.c:493:OQS_API void OQS_KEM_free(OQS_KEM *kem) { liboqs/src/kem/bike/kem_bike.c:9: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/bike/kem_bike.c:34: OQS_KEM *kem = malloc(sizeof(OQS_KEM)); liboqs/src/kem/bike/kem_bike.c:59: OQS_KEM *kem = malloc(sizeof(OQS_KEM));

[baentsch]

Question: 'bike', 'frodokem', 'ntruprime' is not from upstream.

Good point. @dstebila : There's surely upstreams for these algorithms, but they're not captured by OQS automation/copy_from_upstream. Question: Are these projects still maintained (and where) or is it OK to change code straight in liboqs for these algs? If the former, what would it take to bring them in via "copy_from_upstream"? If the latter, should we remove them completely from OQS?

[dstebila]

Question: 'bike', 'frodokem', 'ntruprime' is not from upstream.

Good point. @dstebila : There's surely upstreams for these algorithms, but they're not captured by OQS automation/copy_from_upstream. Question: Are these projects still maintained (and where) or is it OK to change code straight in liboqs for these algs? If the former, what would it take to bring them in via "copy_from_upstream"? If the latter, should we remove them completely from OQS?

FrodoKEM is maintained at https://github.com/microsoft/PQCrypto-LWEKE/; I exported the code from there any manually added it to liboqs, as we didn't have as robust a copy_from_upstream at the time. FrodoKEM also needs to do an update from upstream, as there have been new variants introduced in the last year, but I don't have a plan for this update. So to avoid blocking on that, I would say it's fine to make the FrodoKEM changes directly here in this repository.

NTRUPrime had been coming from PQClean, but they have stopped supporting it. We only are keeping one variant of NTRUPrime because of its use in OpenSSH. I think we consider a timeline for sunsetting it. But in the interim, I think changes to NTRUPrime can be done directly here in this repository.

BIKE was contributed directly by the team at AWS. Our main contact for that has been @dkostic, but I'm not sure if he's still the right contact. Pinging @brian-jarvis-aws for some input.

[songlingatpan]

@dstebila @baentsch @bhess @jschanck
Code change for openssl allocator has been done.
Please review the code.

In addition, there are quite some error handling and potential memory leak.
Would you like to fix them in the current PR? or create a separate PR for review?

Thanks

[songlingatpan]

**baentsch ** requested changes

done

[dstebila]

In addition, there are quite some error handling and potential memory leak. Would you like to fix them in the current PR? or create a separate PR for review?

I'd prefer to see those as a second PR, since those changes may be less mechanical and might require a closer look.

[dstebila]

I suggest we defer merging this until after the 0.11.0 release, otherwise we would need to cut a new release candidate and push the release back a week.

[songlingatpan]

Thanks for this work, @songlingatpan!

How would you feel about dropping the OQS_MEM_free function and instead using OQS_MEM_insecure_free (presumably modifying it to use OPENSSL_free)? I think it's a good idea to have a clear separation between "insecure" and "secure" frees, and we lose that if we introduce a not-explicitly-insecure free function with the same signature as OQS_MEM_insecure_free.

Addressed the comment in the latest PR. Please review it.

[songlingatpan]

After this lands, we may want to add some sort of static analysis to guard against raw malloc or free calls. Seems like something related to #1868.

Correct. We should phase out direct calls to malloc, free, calloc, strdup, and realloc.

[dstebila]

After this lands, we may want to add some sort of static analysis to guard against raw malloc or free calls. Seems like something related to #1868.

Correct. We should phase out direct calls to malloc, free, calloc, strdup, and realloc.

test_free in tests/test_code_conventions.py does this for free calls using an ad hoc script. It may be better to do this with CodeQL in the long run.

[songlingatpan]

test_code_conventions.py

Addressed the comment by adding code in test_code_conventions.py.

[songlingatpan]

@dstebila @baentsch @SWilson4
Is there anything else I need to address before we proceed with merging this PR?

Thanks!

[SWilson4]

@dstebila @baentsch @SWilson4 Is there anything else I need to address before we proceed with merging this PR?

Thanks!

Please take a look at my comments here and here and let me know what you think.

[songlingatpan]

@dstebila @baentsch @SWilson4 Is there anything else I need to address before we proceed with merging this PR?
Thanks!

Please take a look at my comments here and here and let me know what you think.

It seems the conflicts issue only occurs for certain openssl version/platform. Didn't see conflicts any more after revert.

[songlingatpan]

@SWilson4 Addressed your 2 comments.
Please let me know if I need to run copy_from_upstream.py or any other scripts to regenerate code before merge.
If so, what is the detail steps.

[songlingatpan]

@dstebila @baentsch @SWilson4
I have addressed existing comments. Please let me know if we can merge the PR.
Thanks

[baentsch]

if I need to run copy_from_upstream.py or any other scripts to regenerate code before merge.

It's always a good idea to run those to preclude CI finding issues. See e.g. this CI workflow. @SWilson4 : Maybe a sensible addition to CONTRIBUTING.md?

[baentsch]

Please let me know if we can merge the PR.

@songlingatpan please see a single comment I just added (creating an issue to track a problem pointed out by @SWilson4 )

@SWilson4 would you please mark all your comments resolved that you consider such? Makes reviewing reviews easier (at least for me).

[songlingatpan]

Please let me know if we can merge the PR.

@songlingatpan please see a single comment I just added (creating an issue to track a problem pointed out by @SWilson4 )

@SWilson4 would you please mark all your comments resolved that you consider such? Makes reviewing reviews easier (at least for me).

No need additional code changes for upstream:
python3 copy_from_upstream.py copy && ! git status | grep -i modified
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/bike.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/classic_mceliece.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/frodokem.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/hqc.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/kyber.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/ml_kem.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/kem/ntruprime.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/cross.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/dilithium.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/falcon.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/mayo.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/ml_dsa.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig/sphincs.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig_stfl/lms.md
Updating /home/shan/oqs_github/liboqs/docs/algorithms/sig_stfl/xmss.md
Updating README.md

[songlingatpan]

@SWilson4
Please let me know if anything else I need to address in this PR.