Dear all,
While I was working on the PSoC64 platform, I hit the *psa_key_id_t* type mismatch problem.
The patch - *98ab441e096f *enables *MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER* Which in terms to use the *psa_key_id_t* *structure* (psa_key_file_id_t) in <mbed-crypto/mbedtls>/include/psa/*crypto_platform.h* Interestingly, psa_key_id_t is also defined in <tf-m>/interface/include/psa/ *crypto_types.h*, as a uint32_t.
So, I do the following testing I could compile the master HEAD no problem *66ee5c8861* (HEAD, origin/master, origin/HEAD) Tools: update iat-verifier README and samples
I assume the psa_key_id_t should be a *structure* (from mbed-crypto/mbedtls), I applied the patch below
--- a/interface/include/psa/crypto_types.h +++ b/interface/include/psa/crypto_types.h @@ -211,6 +211,8 @@ typedef uint8_t psa_key_persistence_t; */ typedef uint32_t psa_key_location_t;+#if !defined(MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER)+#error Should not compile this /** Encoding of identifiers of persistent keys. * * - Applications may freely choose key identifiers in the range @@ -222,6 +224,7 @@ typedef uint32_t psa_key_location_t; */ typedef uint32_t psa_key_id_t; #define PSA_KEY_ID_INIT 0+#endif
Then, I notice that there are still many files that use *uint32_t* psa_key_id_t in the TF-M source tree.
a) It's good (lucky?) that TF-M seems to cut it cleanly so it doesn't run into problems (well, it happens on PSoC64, or I won't notice it). b) It's bad that psa_key_id_t in TF-M has two different types.
I'm not going to argue what's correct/wrong. Maybe this kind of coding could be a feature in the future. I just go with it. But I found no information to define the boundary of the two types under the <tf-m>/docs/ directory. I would like to know where the boundary is, in TF-M. In other words, *Which part of the code should use the structure definition from mbedtls/mbed-crypto; which part of the code should use uint32_t ?*
In my work, the problem happens when it passes psa_key_id_t as a parameter, the parent & child functions see it differently (HardFault, in my case, memory violation to other parameters). e.g.: func_a.c (structure), func_b.c (uint32_t). func_b.h ---- the type changes when it's included by func_a.c and/or func_b.c
Regards, Alamy