Hi Michel,
Thank you for your quick answer and fix.
For the long term, could-it be a good idea to add a tfm_hal_ function to allow chip specific locking mechanism such as SYSCFG_CSLOCKR once the AIRCR has been done by the tf-m ?
From my perspective, this is the tf-m role to set-up the AIRCR configuration and even if this register is set-up by ST port, locking-it at this stage prevent the tf-m from doing its own modification. For now the AIRCR is set-up in accordance of what is expected later by the tfm-m but it could not be true for future tf-m development.
Thank you,
Best regards,
Romain De : Michel JAOUEN via TF-M tf-m@lists.trustedfirmware.org Envoyé : jeudi 24 février 2022 18:29 À : JAYLES Romain Romain.JAYLES@cea.fr; tf-m@lists.trustedfirmware.org Objet : [TF-M] Re: Locking of PRIS bit in AIRCR register
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.orgmailto:tf-m@lists.trustedfirmware.org> Sent: jeudi 24 février 2022 17:53 To: tf-m@lists.trustedfirmware.orgmailto: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