We need to be cognizant of the target usage and user base. The vast majority of usage is v8m in which case the HAL can be simple and targeted for TrustZone.  Based on what I have witnessed other than the changes required to support dual/multicore usage.  Why not offer a HAL option for TrustZone and one for dual/multicore?  

 

All the best!

Reed

 

Hi,

 

I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it’s important to consider what’s platform specific and what’s generic.

 

In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world.

 

I don’t disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context.

 

Thanks,

Abhishek

 

 

Hi Jonatan,

 

The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate:

 

• The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the ‘system isolation’ mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able.
• How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status.

 

So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere).

 

I would suggest not to propose the calling time strictly for this new enhanced API.

 

I know cypress uses customized protection initialization mechanism so any ideas?

 

BR

 

/Ken

 

 

Hi all,

 

I am trying to align TrustZone initialisation procedure between TF-M and CMSIS.

 

In CMSIS the approach from the early v8-M days is to have a “partition.h” file providing “TZ_SAU_Setup()” function. This function is called during low level “SystemInit()” which runs as part of the pre-main (called from ResetHandler and before running C lib init).

 

In contrast TF-M calls “tfm_spm_hal_init_isolation_hw()” (which is similar to “TZ_SAU_Setup()” plus PPC/MPC configuration) during “tfm_core_init()” (which runs in secure “main()”).

 

The advantage of “TZ_SAU_Setup()” is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn’t cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a “TrustZone_Setup()” function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code.

 

The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the “system isolation” already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code.

 

Cheers,

 

Jonatan Antoni

Senior Engineering Manager - CMSIS

 

Arm Germany GmbH
Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19

Email: jonatan.antoni@arm.com | Visit: www.keil.com | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309

Geschäftsführer: Joachim Krech, Reinhard Keil

 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.