Hi everyone! 

I am currently integrating TF-M with an IoT OS (RIOT OS) and I have a few problems.
I managed to build and link a secure TF-M binary and a non-secure RIOT binary and I can run some application code (print "hello world", turn LEDs on and off, etc) on the nRF9160dk. I can also use the crypto API and call psa_crypto_init.
Now I have tried a few things and each of them leads to different problems, some of which I will describe in this mail hoping that someone can help me with this.
I have done some debugging and have some ideas on what could be wrong, but I don't really understand how to fix the issues and don't really know how to proceed with either of them.

Formatted Prints
Somehow formatted prints are ignored. Calls to printf  without formatting default to the stdio puts implementation and are printed without issues. Calls to printf with formatting use the implementation in tfm_sp_log_raw.c and are just ignored. They crashed at first, but I could fix that (RIOT has different implementations of the SVC ISR and I used the wrong one). Now they don't crash anymore, but are also not printed (no error output, application keeps running). Since this function is part of the secure firmware, my guess is that there's a problem with it being called from the NS world. But that should result in a SecureFault, shouldn't it? Does anyone have an idea what the issue could be?

Secure memset called from NS image
When calling psa_generate_key, the first step is a struct initialization:

struct tfm_crypto_pack_iovec iov = {
    .function_id = TFM_CRYPTO_GENERATE_KEY_SID,
};

This runs into a SecureFault. It turns out that during struct initialization, memset is called to zeroize the structure. This uses the memset implemented in secure_fw/shared/crt_memset.c and accesses secure RAM (between addresses 0x20015000 and 0x20016000). I found a workaround by moving the start address of NS RAM from 0x20016000 to 0x20020000. Memset now still accesses RAM before NS RAM, but does not run into a SecureFault anymore. This works for now, but I would like to find an actual fix for this.
This only occurs when building with RIOT. When building the TF-M NS image and running crypto tests, memset accesses NS RAM, though I don't know if the same implementation is used. Unfortunately I don't get any debug symbols there. Could it be that a different memset implementation should be linked? Can I change it somehow? Can someone tell me which one is linked in the TF-M NS image?
    
Crypto partition is NULL
When using the workaround described above, calling psa_generate_key runs into tfm_core_panic. The stack trace here is:

psa_call (tfm_psa_call.c)
tfm_psa_call_pack (backend_sfn.c)
tfm_spm_client_psa_call (psa_call_api.c)
tfm_spm_is_ns_caller (spm_ipc.c)

The problem is in tfm_spm_is_ns_caller, where 

struct partition_t *partition = GET_CURRENT_COMPONENT(); 

gets a NULL pointer. So somehow there is no crypto partition available.
Of course I have enabled the crypto partition in config_base.cmake, as well as protected storage and internal trusted storage. I checked with a debugger and found out that during start up, multiple partitions are initialized and added to the global component list (stored in backend_sfn.c). Can I somehow check what types of partitions are  initialized?
Did anyone have a similar issue before or has any idea why the partition could be missing? Did I miss any extra steps I need to take?

I know these are pretty much unrelated issues, but they are persistent and I am at a loss at how to fix them.
I will take any hints and ideas, including pointers to where I can find relevant information in the docs (those have not been very helpful in these cases, but maybe I've overlooked something).

Best regards,
Lena