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...). 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