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