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

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

erik.johnson — Wed, 10 Feb 2021 02:07:02 GMT

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!

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

Håkon Alseth — Mon, 16 Nov 2020 14:29:49 GMT

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

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

erik.johnson — Fri, 13 Nov 2020 14:56:41 GMT

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.

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

erik.johnson — Fri, 13 Nov 2020 14:55:12 GMT

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.

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

Håkon Alseth — Thu, 12 Nov 2020 15:05:12 GMT

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

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

Håkon Alseth — Tue, 10 Nov 2020 14:48:35 GMT

Hi Erik,

My apologies for the long waiting time.

[quote user=""]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?[/quote]

After a bit of back-and-forth, I can confirm that the *NSC[n].SIZE registers can be configured up to 4k each.

Each NSC function will generate a 2 word veneer (see linker symbols __sg_start / __sg_end), placed in section "sgstubs" (linker script found here). Here's an example from secure_services:

 .gnu.sgstubs.__stub
                0x0000000000007fe0       0x18 linker stubs
                0x0000000000007fe0                spm_firmware_info_nse
                0x0000000000007fe8                spm_request_random_number_nse
                0x0000000000007ff0                spm_request_read_nse
                0x0000000000008000                __sg_end = .
                0x0000000000000020                __sg_size = (__sg_end - __sg_start)
                0x0000000000008000                . = ALIGN (0x8000)
                0x0000000000000020                __nsc_size = (. - __sg_start)
                0x0000000000000001                ASSERT (((__sg_size == 0x0) || ((((0x1 << LOG2CEIL ((0x8000 - (__sg_start % 0x8000)))) == (0x8000 - (__sg_start % 0x8000))) && ((0x8000 - (__sg_start % 0x8000)) >= 0x20)) && ((0x8000 - (__sg_start % 0x8000)) <= 0x1000))), The Non-Secure Callable region size must be a power of 2 between 32 and 4096 bytes.)

This is a limiting factor on the total amount of NSCallable functions, where its maximum allocation is 512 functions (4096 / 8 bytes) per region.

[quote user=""]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?[/quote]

I am sorry, but I do not have an update for this issue yet. I'm still checking internally. Consider this item still open from our side.

Kind regards,

Håkon

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

erik.johnson — Wed, 04 Nov 2020 11:47:00 GMT

Hi Håkon, no worries. Thanks for the update!

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

Håkon Alseth — Tue, 03 Nov 2020 15:28:10 GMT

Hi,

My apologies for the late response.

I am in contact with key personnel in R&D related to your questions, and I hope to give you a response within a few working days, and if not; a status on the progress.

Kind regards,

Håkon

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

erik.johnson — Thu, 29 Oct 2020 18:09:32 GMT

Two updates:

1) Looks like RAMNSC will hold more than 4 bits. I would assume the documentation (and the "mask" in nrf9160.h) is incorrect that it only holds 4 bits, but rather it holds 5 and is in increments of 8K still?

2) I made a manual "veneer" RAM function that used BX to jump to the SG instruction in flash, but that succeeded, unlike when in RAM. So, it seems like there's no limitation on BL versus BX. Which means I've now run out of ideas as to what's going on.

Hopefully either someone in the community or at least at Nordic has accomplished this at some point...