Can't get RAM-based Secure Entry functions to work

[erik.johnson]

I'm having trouble getting the Secure Entry gateway functions to work out of RAM. The nRF9160 datasheet has RAMNSC configurations, so it should be possible. We're able to get flash-based ones to work. Has anyone been able to have RAM-based Secure Entry functions?

I've confirmed the configuration of RAMNSC as well as RAMREGION in the SPU. It looks like the nRF9160 documentation has an error, however: it says the RAMNSC regions are 8K each, but there are only enough bits for 16K. Can anyone confirm if that's an error? Or perhaps it just doesn't support the full RAM range as NSC?

The only real difference I've noticed (beyond the annoying wrangling to get GCC to do what I want it to) is that there are "veneer" function calls for RAM functions that aren't used when calling the flash counterparts. In particular, it looks like the branch to the SG instruction in flash is a BL, while the branch to the SG instruction in RAM from the veneer is BX. I haven't been able to find any documentation on whether or not various branching methods work or don't work with TrustZone transitions. Is there any info on if BX will work?

[erik.johnson]

I finally got a chance to revisit this, and was able to get it all working with a bit of fussing with linker scripts and setting up my own veneer functions with some assembly. So, I can confirm RAM-based NSC is working on the nRF9160!

[Håkon Alseth]

Could you share a bit more details related to where your veneers are located, what the content on those RAM addresses are, and how your RAMNSC[] register content is setup?

Do all NSC calls fail, even the spm_busy_wait_nse() function?

 

Kind regards,

Håkon

[erik.johnson]

I've been able to work around these issues with some adjustments. I can confirm from my debugger (and nrfjprog.exe, for that matter) that the instructions are getting set up at our RAM locations. It's just that the system gives a Secure Fault when they're used, hence the questions about configuring RAMNSC.

[erik.johnson]

Were you able to confirm *NSC[n].REGION is every 4K/8K/16K? We'll be using the smallest size for *NSC[n].SIZE (32 bytes) anyway, so I'm not worried about the size limit for it. But I want to make sure the region I'm selecting is actually getting set correctly.

I'm quite certain it can't be every 4K for the region selections, since the register won't hold more than 5 bits (confirmed after trying to put 63 in the register, but only reading back 31 after the write). But I want to make sure it's not a silicon bug where only the first half of RAM can be used for NSC entries or something.

[Håkon Alseth]

Hi,

 

I have been in contact with several low-level developers, and I have some bad news. I am afraid that we do not have any example that shows how to use non-secure callable RAM located functions using RAMNSC. It was considered, and looked into, but it was not viable at the time.

The reason for this is due to the zephyr build environment and the features of the gnu linker (see this: https://answers.launchpad.net/gcc-arm-embedded/+question/478082).

 

Kind regards,

Håkon