Hello happy taxpayers
[EDIT #1]
I forgot to say that what is really working is that is, from non secure app, I try to write in secure SRAM, then I end in the secure fault handler of my secure app. So, in this direction it's really clear the expected behaviour, but not in the other direction.
[END EDIT #1]
I'm completely lost with this definition from the STM32U5 reference manual, in paragraph 5.4.2 of the GTZC:
"illegal secure access : Any secure transaction trying to access nonsecure block in internal block-based SRAM or watermarked memory is considered as illegal. Correct TZIC settings allows the capture of the associated event and then generates the GTZC_IRQn interrupt to the NVIC. This applies for read, write and execute access.
Concerning the MPCBB controller, there is an option to ignore secure data read/write access on nonsecure SRAM blocks, by setting the SRWILADIS bit in the GTZC_MPCBBz_CR register."
From my point of view, what I understand is that if, from my secure app, I try to write or read in the SRAM of the non secure app, then I must end in the GTZC handler, or (note: the RM does not say that) in the secure fault handler.
But I can never see that, on the opposite I can always write to the non secure SRAM.
I tried a lot of things each time in the best scenario nothing change and in the worst case I end in a hard fault.
Here now more context and my setup.
I work in a IAR workspace, and build right now for a Nucleo U575ZI-Q dev kit.
FLASH is split in exactly 2 part: bank 1 secure, bank 2 non secure, to make thing easier ;)
secure app is built (linker script) for using SRAM1, aka from 0x3000 0000
non secure app is built (linker sinker script) for using SRAM2, aka from 0x2003 0000
In secure app, MPCBB configures SRAM2 to be
- non secure, non proviledge
- secure r/w access not allowed : this is the important assertion I want to test
Nothing too fancy, this is usualy what CubeMX generates as code.
/* Secure read/write access not allowed on nonsecure SRAM block*/
MPCBB_Area_Desc.SecureRWIllegalMode = GTZC_MPCBB_SRWILADIS_ENABLE;
/* SRAMs clocks are secure if a secure area exists in the MPCBB. It is nonsecure if there is no secure area */
MPCBB_Area_Desc.InvertSecureState = GTZC_MPCBB_INVSECSTATE_NOT_INVERTED;
/* Set all the SRAM2 memory security to non-secured */
MPCBB_Area_Desc.AttributeConfig.MPCBB_SecConfig_array[0] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_SecConfig_array[1] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_SecConfig_array[2] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_SecConfig_array[3] = 0x00000000;
/* Set all the SRAM2 memory access to unprivileged */
MPCBB_Area_Desc.AttributeConfig.MPCBB_PrivConfig_array[0] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_PrivConfig_array[1] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_PrivConfig_array[2] = 0x00000000;
MPCBB_Area_Desc.AttributeConfig.MPCBB_PrivConfig_array[3] = 0x00000000;
/* All the SRAM2 memory is unlocked (meaning that its secure settings can still be modified) */
MPCBB_Area_Desc.AttributeConfig.MPCBB_LockConfig_array[0] = 0x00000000; /* @todo: should be locked at some point */
/* @todo: handle returned error code */
HAL_GTZC_MPCBB_ConfigMem(SRAM2_BASE, &MPCBB_Area_Desc);
Based on just this, I can always, from the secure app, write in SRAM2, for instance this:
*(uint32_t*)(0x20030000) = 0x42424242;
Is working just fine, that is:
- jump to non secure app is effective
- I can see the values in SRAM2
- not any fault: no hard fault, no bus fault, no secure fault, nada
I enabled GTZC IRQ:
HAL_NVIC_SetPriority(GTZC_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(GTZC_IRQn);
it makes no difference: no GTZC IRQ when I write to SRAM2, still no exception.
Then I thought, "oh yes, SRAM2 must pass through GTZC" so I added this:
if (HAL_GTZC_TZSC_ConfigPeriphAttributes(GTZC_PERIPH_SRAM2, GTZC_TZSC_PERIPH_NSEC|GTZC_TZSC_PERIPH_NPRIV) != HAL_OK) {
//TODO do something
}
if (HAL_GTZC_TZIC_EnableIT(GTZC_PERIPH_SRAM2) != HAL_OK) {
//TODO do something
}
and it's completely useless : the call to HAL_GTZC_ConfigurePeriphAttributes returns immedialty HAL_ERROR (I did not look at what test failed). I do not know the effect of HAL_GTZC_TZIC_EnableIT here.
Time for a break: right now I'm completely lost with this, so I tried another approach and create a new project from scratch with CubeMX, since I thought that maybe there is a relation with SAU configuration that I missed (I read nothing about a link between SAU and MPCBB in reference manual, but give it a try).
So, CubeMX, new project from board, with TrustZone enable, activate SAU and only 1 region (not the 6 one by default) and make this region non secure and match SRAM2:
Do not modify anything in generated code, build secure, build non secure, start debug session: this is an immediate disaster, code ends in hard fault :face_with_tears_of_joy:
Ok, back to previous step: enable SAU but do not change its default configuration from MX: no problem in that case, the app does nothing but it runs (trapped in the while (1) loop of main( ) in the non secure).
Great: now if I try to write in SRAM3 (aka 0x2004 0000) ? Well, no problem, I can write this way:
*(uint32_t*)(0x20040000) = 0x42424242;
So, obviously I missed something, something I did not understand in the definition of "illegal secure access"
Is there anyone to guide me with that ?
Thank you all
P.
