Hi everyone,
The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries.
Hence, a deeper abstracted interface are provided. Here are the details:
- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.
- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).
- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.
- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.
- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.
We created a patch to showcase the usage on AN521:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.
Now come to the request:
Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.
Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.
Any feedbacks are welcome.
Thank you very much!
/Ken
Hi Anton,
I'd like to introduce the proposal of out-of-tree Secure Partition build.
It may take 15 ~ 20 mins.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, August 17, 2021 5:49 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - Aug 19
Hi Anton,
I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it.
Would take ~20 min.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, August 17, 2021 5:26 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] Technical Forum call - Aug 19
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Anton,
I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it.
Would take ~20 min.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, August 17, 2021 5:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - Aug 19
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Ken,
“double-check every return value of sub-functions, this is really a burden when under developing”
That’s exactly why FIH can help mitigate physical attacks. It adds redundant checks and increases the complexity in code to make it difficult for attackers.
It of course also increase develop efforts and it is expected for physical attack mitigation.
Regarding tight schedule, it can be workaround by splitting the HAL API definitions with and without FIH enabled respectively.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:54 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Thanks, then we can do some planning and make the FIH feature online again before the deadline.
I do agree FIH needs an update. There would be reasons for HAL to change its implementation or prototype; and the existing FIH needs another copy of implementation, change the prototype a bit, and double-check every return value of sub-functions, this is really a burden when under developing: We first need to ensure the non-FIH version work, get reviewed; and then prepare the FIH version, get reviewed again. And, the platform owner may be afraid of changing the HAL implementation, as it is risky to do that.
I’d suggest enhancing the solution that:
- Doing measurement without changing HAL API prototype.
As the bandwidth is always a problem, so I have to prioritize the designs. Let’s see if we can get help from people. Otherwise, I will allocate some effort after HAL update is done. This means, there would be a couple of HAL updates with no FIH support recently, and FIH version comes later.
Any volunteer is welcome.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:39 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Next platform with FIH enabled is foreseen to be in V1.5.0 with FIH enabled (the pull request without FIH enabled is expected in september)
FIH support is planned on later pull request.
So FIH recovering needs to be done at least 3 weeks before V1.5.0 code freeze, to let the time to do adaptation/test /fix on this new platform.
Best Regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: jeudi 12 août 2021 10:34
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:26 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: mercredi 11 août 2021 07:24
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when “recovering back”: if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome – that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won’t weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are “recovered back”.
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 9, 2021 10:18 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hello,
Next platform with FIH enabled is foreseen to be in V1.5.0 with FIH enabled (the pull request without FIH enabled is expected in september)
FIH support is planned on later pull request.
So FIH recovering needs to be done at least 3 weeks before V1.5.0 code freeze, to let the time to do adaptation/test /fix on this new platform.
Best Regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: jeudi 12 août 2021 10:34
To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:26 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: mercredi 11 août 2021 07:24
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 9, 2021 10:18 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: mercredi 11 août 2021 07:24
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 9, 2021 10:18 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: mercredi 11 août 2021 07:24
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 9, 2021 10:18 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hi all,
Can I ask you to review the following patch set to enable out-of-tree secure partition build in TF-M?
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10562/
The purpose is to enable developers to develop their own secure partitions outside TF-M repo. Developers can maintain their own code and repos, independently.
Developers can pass their out-of-tree secure partition paths via TF-M command line, to build out-of-tree partitions with TF-M together.
For more details, please check the updated document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10696
Suggestions and comments are welcome!
Best regards,
Hu Ziji
Hi,
A platform binding HAL API "tfm_hal_bind_partition()" is being introduced to TF-M.
This API lets the platform records partition information, and applies specific settings. An encoded handle is returned to SPM, so that SPM can use the handle to decide when and how to update isolation boundaries. The "tfm_hal_update_boundaries()" API is updated accordingly.
Check details in the patch.
Implementation on AN521 is here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
Any feedback and comments are welcome :)
Thanks,
MIngyang
