Move private headers to a private directory

[amtkarm1]

Description

Fixes Mbed-TLS/mbedtls#10087.

PR checklist

• TF-PSA-Crypto PR provided Move private headers to a private directory TF-PSA-Crypto#318
• development PR provided Move private headers to a private directory mbedtls#10224
• 3.6 PR not required because: no backport required

[mpg]

This is good for development, but the framework needs to keep working with 3.6 as well. I suggest

#if MBEDTLS_VERSION_MAJOR >= 4
#include <mbedtls/private/bignum.h>
#else
#include <mbedtls/bignum.h>
#endif

(Here and in all similar places obviously.) (Edit: MBEDTLS_VERSION_MAJOR is defined by including build_info.h which should already be included everywhere.)

I also suggest you create a "shadow" 3.6 PR where the only thing you do is change the framework pointer to the head of this PR.

Your goal is now to get a green CI both on the mbedtls development PR and the shadow 3.6 PR :)

[valeriosetti]

I also suggest you create a "shadow" 3.6 PR where the only thing you do is change the framework pointer to the head of this PR.

Based on the results of CI for this PR it seems to me that:

1. development of tf-psa-crypto: OK
2. development of mbedtls repo: FAIL
3. mbedtls-3.6 of mbedtls: OK

As far as I can tell 3.6 testing should be fine, but then I'm a bit surprised that tf-psa-crypto is also OK with the files being moved while development of mbedtls repo fails. I would expect both to fail for the same reason, i.e. files being moved. This made me think on the proposed suggestion of #if MBEDTLS_VERSION_MAJOR >= 4: shouldn't we also check PSA_CRYPTO_API_VERSION_MAJOR for the case in which tf-psa-crypto repo is built as standalone?

[gilles-peskine-arm]

Not PSA_CRYPTO_API_VERSION_xxx: that's the API version which is irrelevant. We'd need TF_PSA_CRYPTO_VERSION_xxx (or whatever the name is supposed to be) which doesn't exist yet.

[valeriosetti]

OK, thanks for the details!
Therefore I suspect that we might have issues with this PR series as follows. CI tests in this PR for standalone tf-psa-crypto here are passing just because the the current default branch of tf-psa-crypto is used and the old headers' path is picked. But there are tests on Mbed-TLS/TF-PSA-Crypto#318 which are failing due to missing test headers (I didn't check them all, but at least test_tf_psa_crypto_out_of_source does):

[2025-06-24T10:46:42.522Z] [  1%] Building C object CMakeFiles/tf_psa_crypto_test.dir/framework/tests/src/bignum_helpers.c.o
[2025-06-24T10:46:42.522Z] In file included from /var/lib/build/framework/tests/src/bignum_helpers.c:14:
[2025-06-24T10:46:42.522Z] /var/lib/build/framework/tests/include/test/bignum_helpers.h:23:10: fatal error: 'mbedtls/bignum.h' file not found
[2025-06-24T10:46:42.522Z] #include <mbedtls/bignum.h>

[mpg]

Yeah, sorry, my suggestion was not correct, I noticed and discussed it on Slack but failed to report the outcome of the discussion here. I think while waiting for TF_PSA_CRYPTO_VERSION_xxx I suggest

#if !defined(MBEDTLS_VERSION_MAJOR) || MBEDTLS_VERSION_MAJOR >= 4
#include <mbedtls/private/bignum.h>
#else
#include <mbedtls/bignum.h>
#endif

In tf-psa-crypto standalone, MBEDTLS_VERSION_MAJOR will not be defined. In mbedtls development, it will be defined and >= 4. Those are the two cases where we want the new path. In mbedtls 3.6, it will be defined and < 4; this is the only case where we want the old path.

(Alternatively, we could make this whole series of PRs depend on c323 but I'd rather not: this is a very conflict-prone series of PR so we should try not to delay it if we can avoid it.