search

Mbed-TLS / mbedtls

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
https://www.trustedfirmware.org/projects/mbed-tls/
Other
5.02k stars 2.5k forks source link

Add make build system in tf-psa-crypto directory #9282

Open ronald-cron-arm opened 1 week ago

ronald-cron-arm commented 1 week ago

Suggested enhancement

In preparation of the split, add a make build system to build the crypto library, the PSA programs and the crypto test suites in the tf-psa-crypto directory. It should be an adaptation of the Mbed TLS make build system to the crypto code in tf-psa-crypto directory: one Makefile in tf-psa-crypto, tf-psa-crypto/core, tf-psa-crypto/programs, tf-psa-crypto/tests. In this issue no change to the mbedtls make build system.

Depends on #9261, #9262, #9263, #9266 and #9267.

DoD: . make (all|no_test|programs|lib|tests|clean|test|check|generated_files|neat) run successfully with a similar outcome as for the whole mbedtls repo. . make (apidoc|apidoc_clean|lcov|cscope|install|uninstall) not in scope of this issue.

Justification

Mbed TLS needs this for the repo split.

gilles-peskine-arm commented 1 week ago

So the big question: are we splitting the existing makefiles, or creating new ones from scratch? And if new ones, how?

ronald-cron-arm commented 1 week ago

So the big question: are we splitting the existing makefiles, or creating new ones from scratch? And if new ones, how?

I am proposing a middle-ground solution in this issue: we adapt the makefiles we have in mbedtls to tf-psa-crypto code (and we do not change the mbedtls ones in this issue, mbedtls build systems using tf-psa-crypto build systems would be done later as part of another issue and eventually it will be a split of the existing makefiles). That way we should end up with a make build system for tf-psa-crypto similar to the one we have for mbedtls and the work and reviews should not be too complicated. Here I try to eventually split the build systems, not change/improve what we have.

Another way to say it: the proposal is to eventually split the existing makefiles but this issue is just a first step.

gilles-peskine-arm commented 1 week ago

I'm not sure about “should not be too complicated”. Our existing makefiles are pretty complex and error-prone. They're also error-prone in day-to-day work because they don't have correct dependencies. I am not convinced that a clean-slate approach would be slower. And we don't even have to start from a clean slate, since I've offered a cleaned-up version of an implementation that has been working well for one user for several years.