Hello,

Thanks for the report.

For fixing this issue without removing an early lock of vector modification , an option is to perform an early configuration.

See  https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14129

Best Regards

Michel

ST Restricted

From: JAYLES Romain via TF-M <tf-m@lists.trustedfirmware.org>
Sent: jeudi 24 février 2022 17:53
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Locking of PRIS bit in AIRCR register

Hi all,

We are currently testing the tfm-m implementation on a STMicroelectronic chip: stm32u5 board.

This stm32u5 has a special register: SYSCFG_CSLOCKR (see https://www.st.com/resource/en/reference_manual/rm0456-stm32u575585-armbased-32bit-mcus-stmicroelectronics.pdf). This register allows to lock the PRIS bit of the AIRCR register from further modification.

The issue here is that, in the ST implementation, thanks to this SYSCFG_CSLOCKR, the PRIS bit of the AIRCR is locked at boot (Reset_Handler in file startup_stm32u5xx_s.c). Resulting in the function tfm_arch_set_secure_exception_priorities() not being able to set the PRIS bit of the AIRCR. This situation lead to big issues at runtime as interrupt priority of NSPE are able to pre-empt interrupt of SPE.

Disabling the locking of PRIS bit solve our problem but currently we don’t see a clean way to integrate chip specific security features (something like callback/tfm_hal_ ) after the function tfm_arch_set_secure_exception_priorities() has been called.

What would be the best way to fix the current issue which could also arise on other platform ?

Regards,

Romain