Sorry all, this is a *FALSE* alarm. Although some codes still include the local header file (*uint32_t*), *none* of them use *psa_key_id_t* at all. Maybe the code should be more clean, but there is no run-time problem!

Sorry if it causes problems, Alamy

On Mon, Aug 31, 2020 at 8:38 AM Alamy Liu alamy.liu@gmail.com wrote:

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