Enabling TrustZone non-secure internal flash and ram reads as zero from secure state

[Meixner]

I am trying to use TrustZone on STM32U5A9:

I am setting up the following regions in SAU:

1. 0xc1fe000-0xc1fffff non-secure callable
2. 0x8200000-0x83fffff non-secure
3. 0x200c0000-0x20273fff non-secure
4. 0x60000000-0x6fffffff non-secure

As soon as I flip the enable flag in the SAU control register, the non-secure marked regions become invisible to secure code and start to read as zero. This contradicts the ARM documentation, which says that secure code can read non-secure memory.

So what am I missing?

[CMYL]

Dear @Meixner 

Do you configured the MPCBB (memory protection controller - block based) of GTZC (Global TrustZone controller) ?

GTZC is an additional security layer in STM32U5 Series to define secure and privilege state of peripherals and internal RAM. MPCBB configures the internal RAM in a TrustZone-system product having segmented SRAM (pages of 512 bytes) with programmable-security and privileged attributes.

For more details, the RM0456 Rev 4 section 2.2.1 gives the Default Arm TrustZone security state of the STM32U5 after reset. When some are secured by default it is indicated how to change this default state.

 

Best regards,

Younes

 

[Meixner]

In the meantime I got it working. What was not really clear was that the GTZC configuration must match the SAU/IDAU configuration.

The ARM documentation that secure code may access non-secure regions does not apply for the case that the SAU/IDAU configuration does not match the GTZC/MPCBB configuration.

[CMYL]

I confirm the default configuration may not allow secure code to access non-secure regions when GTZC is not configured.

However, the SAU can configure a maximum of 8 regions. This TrustZone architecture is extended to define more granularity via GTZC for memories, peripherals and external memories.

[mg28]

Dear @CMYL,

I would like to join in here with my question.

Suppose I have defined a 64KB secure region (SRAM) and a 64KB non-secure region (SRAM) with SAU.

If I use the MPCBB to

a) configure certain blocks of the secure region as non-secure or

b) configure certain blocks of the non-secure region as secure

this has no effect, right?

So in case a) the blocks are still not accessible to code running in a non-secure region, and in case b) the blocks are still accessible to code running in a non-secure region, right?

If I understood correctly, I didn't really understand the benefit and specifically the “more granularity” provided by GTZC/MPCBB.

Thanks in advance.