Flash Access possible from lower to higher security tier

[simon_ott]

I tested reading, writing and erasing flash of the highest security tier (secure privileged) from a lower security tier (secure non-privileged). As lower security tiers should not be able to access higher security tiers, this should not be possible if the microcontroller was configured correct according to my understanding. I made a test project with two binaries: bl1 (secure privileged, 0x10000000-0x10008000) and bl2 (secure non-privileged, 0x10008000-0x10010000). The SAU is set so that the flash is secure for both projects.

The secure AHB Controller is configured as follows:

ENABLE_SECURE_CHECKING = 0x1 (ENABLED)  
ENABLE_S_PRIV_CHECK = 0x1 (ENABLED)
AHB_SECURE_CTRL->SEC_CTRL_FLASH_ROM[0].SEC_CTRL_FLASH_MEM_RULE[0]     = 0x00000023U; (bl1=secure privileged, bl2=secure non-privileged)

With these settings, I expected bl2 (secure non-privileged) not to be able to tamper with the flash
area of bl1 (secure privileged). First I tried to read the memory with the CPU (memcpy) and it worked
as expected: With ENABLE_S_PRIV_CHECK DISABLED I COULD read the memory, with ENABLE_S_PRIV_CHECK I
could NOT read the memory.

However, with ROM API FLASH_Program() and FLASH_Erase(), I am able to make the flash inacessible even with ENABLE_S_PRIV_CHECK ENABLED.
According to my understanding, this should not be possible. secure non-privileged code should
not be able to tamper with secure privileged code, as this is a higher security level.

I attached a test project that demonstrates the behaviour: in bl1/source/tzm_config.c line 13 the
S_PRIV_CHECK can be enabled or disabled. In bl2/source/main.c line 36 the test case (read/write/erase)
can be set. In the current configuration, the flash is destroyed after bl2 runs and then bl1
does not work anymore, i.e. the microcontroller won't do anything as the flash at 0x0 is inaccessible.

I attached the project in case you want to replicate the behaviour.

Am I missing something in the configuration or is this somehow intended behaviour?

[Sabina_Bruce]

Hello Simon,

Hope you are doing well.

I noticed that the SDK is an older version 2.6.2. Could you please confirm if the behavior is the same with 2.8.0, there have been different improvements since then. Just to make sure that it is not an unknown bug in an earlier version. 

Also could you please provide the version of the IDE, while I test your example from my end.

Best Regards,

Sabina

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------- 

[simon_ott]

I am running MCUXpresso IDE 11.0.0

Unfortunately I cannot. I still use chips with silicon 0A (LPC55S69-EVK Revision A1) and when I tried to migrate to a newer version of the IDE and SDK I ran into a lot of problems. I ordered new boards, hoping this time I will receive silicon 1B, but I am not sure when they will arrive. As soon as I get new boards, I can make a new test project with the newest IDE and SDK.

However, compromising the flash from a lower to a higher security tier cannot be a bug in the SDK in my opinion. So I  would still be interested if this is a configuration problem on my side or a problem on the chip.

[Sabina_Bruce]

Hope you are well.I have been attempting to run your example however I am not successful in reproducing them correctly. I am using the latest versions of LPC55S69 v 1B, SDK 2.8.0 and IDE 11.2, so I am trying to port it to the hello world example in the SDK that uses  multicore as yours. I will update you if I am successful with this.
Apart from this, I have been checking with detail the changes you have made. To clarify some of the information, I'd like to go over just the general concepts of the secure/non-secure privilege check. If you enable secure/non-secure privilege check, the AHB secure controller performs additional check for privilege/non-privilege access. In this case privilege/non-privilege access (defined by either secure or non-secure MPU) has to be aligned with AHB secure controller settings. The privilege/non-privilege check can be separately enabled for secure and non-secure bus transactions. The security of transaction is defined by SAU+IDAU.

The AHB secure controller distinguishes between instruction fetch access and data access. In case of instruction fetch, the strict checking is applied. It means that code has to be executed from the same security level.

It means that if CPU is in secure-privilege mode, the code memory has to be configured as secure-privilege in AHB secure controller as well. In case of data accesses, the privilege code has access to both privilege and non-privilege (user) memory, the non-privilege code has access to non-privilege (user) memory only.

Please note that if CPU is in secure mode, the secure MPU takes effect. In non-secure/normal mode the non-secure MPU takes effect.

To make sure I am understanding you'd like to keep both bl1 and bl2 in secure mode but only differentiate between privilege and non-privilege access is this correct?

Best Regards,

Sabina