Where the framework lives from mbedtls

[gilles-peskine-arm]

As things stand after the TF-PSA-Crypto split, in mbedtls, we have two copies of the framework submodule: one at the root, and one in the tf-psa-crypto directory (coming from the tf-psa-crypto submodule).

In any case, TF-PSA-Crypto must have a framework submodule, because it must be possible to maintain it independently of Mbed TLS. That leaves several ways we can handle the framework.

Independent frameworks

In Mbed TLS, there is a /framework which is used when building the mbedtls libraries and linked into the tests, and there is a /tf-psa-crypto/framework which is used when building the crypto library. These can, in principle, be completely independent.

Benefits:

• When crypto or mbedtls needs a new feature in the framework, it doesn't bother the other project.

Downsides:

• “In principle” is doing a lot of work here. A subtle incompatibility between the two framework versions could be hard to diagnose.
• Working with recursive submodules is more painful than just plain submodules.
• When doing work inside the framework, to test it in both crypto and mbedtls, you pretty much need to commit your changes, then arrange to check out the same commit in the other copy of the framework.

Identical frameworks

In Mbed TLS, there is a /framework which is used when building the mbedtls libraries and linked into the tests, and there is a /tf-psa-crypto/framework which is used when building the crypto library. The two framework submodules always point to the same commit in the mbedtls-framework repository.

Benefits:

• No risk of subtle incompatibility between the framework versions.

Downsides:

• Mbed TLS cannot gain a new framework feature without going through a pull request in TF-PSA-Crypto.

Framework only in crypto

Mbed TLS has no /framework: that is present only in TF-PSA-Crypto and in Mbed TLS 3.6. Mbed TLS always uses /tf-psa-crypto/framework.

Benefits:

• No risk of subtle incompatibility between the framework versions.

Downsides:

• Scripts that are used by both projects need to figure out where to find the framework. But that's fairly easy, apart from the need to add a couple of lines to each sh script and probably add a function to build_tree.py.
• Working with recursive submodules is more painful than just plain submodules.

Framework only at the root

When Mbed TLS uses TF-PSA-Crypto, it makes crypto use /framework. The recursive submodule at /tf-psa-crypto/framework is unused and does not need to be initialized.

Benefits:

• When crypto or mbedtls needs a new feature in the framework, it doesn't bother the other project.
• No risk of subtle incompatibility between the framework versions.
• It's easier to make framework changes: you can test them immediately both in crypto and in the corresponding mbedtls branch.
• Recursive submodules are optional.

Downsides:

• All code in TF-PSA-Crypto needs to be able to look for the framework in ../framework relative to the TF-PSA-Crypto root. But that is already mostly the case at the time of the TF-PSA-Crypto split, because the code was written to work before and after the split. TF-PSA-Crypto refers to the framework through the following:

  • ${TF_PSA_CRYPTO_FRAMEWORK_DIR} in CMake.
  • $FRAMEWORK in all.sh
  • framework_scripts_path.py, .mypy.ini and .pylintrc in Python
  • Several sh scripts are being moved.
  • Paths to framework/data_files in .data files. This can be handled in generate_test_code.py: detect data-file-path arguments and fix up the framework path.

  So we would need to do some initial work, but it's plausible that doing so would save us time overall over the next six months.

Goal of this issue

Determine what we want to do and when.