Hi,

We had evaluated this direction before and can start this topic again if there are major requirements, to leave the platform-specific operations to the platform itself. The reason we have to do it now in SPM is that some of the default platform source code does not cover security settings and we are trying to cover these settings automatically in SPM so that integration can be easier. And now seems these settings cannot be avoided for platform integration, it might be good to leave these operations to the platform.

Ideas?

/Ken

From: Michel JAOUEN via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Friday, February 25, 2022 7:12 PM
To: JAYLES Romain <Romain.JAYLES@cea.fr>; tf-m@lists.trustedfirmware.org
Subject: [TF-M] Re: Locking of PRIS bit in AIRCR register

Hello,

I agree on your remark.

On this platform, the lock was initially done to protect vector modification, that why doing it in early stage is better.

Since the early lock mechanism is done to increase resistance to early fault injection, it can be worth to add a control of this configuration before jumping in non secure, for instance a function fih_int tfm_arch_check_secure_exception_priorities(void)

Could be used. This will allow early programmation and early lock, increase configuration control , and allow error detection on this config.

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

Best regards

Michel

ST Restricted

From: JAYLES Romain <Romain.JAYLES@cea.fr>
Sent: vendredi 25 février 2022 09:07
To: Michel JAOUEN <michel.jaouen@st.com>; tf-m@lists.trustedfirmware.org
Subject: RE: Locking of PRIS bit in AIRCR register

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