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@lists.trustedfirmware.org On Behalf Of Ken Liu via TF-M Sent: mercredi 11 août 2021 07:24 To: tf-m@lists.trustedfirmware.org Cc: nd 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@arm.commailto:David.Hu@arm.com> Sent: Wednesday, August 11, 2021 11:53 AM To: Ken Liu <Ken.Liu@arm.commailto:Ken.Liu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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