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