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
Hi Jamie,
10-2020-q4-major is the latest release version. I have no idea on when the defect can be fixed in the future GCC 10 release. I think you can query that information in the tools community
https://community.arm.com/developer/tools-software/tools?_ga=2.153861944.16….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 5:50 PM
To: David Hu <David.Hu(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TF-M v1.4.0 release started
Hi David,
The ARM GCC 10 build from https://developer.arm.com/tools-and-software/open-source-software/developer… does indeed seem to be the cause of the issue, tests are now all passing. Do you know on any timeframe for when an updated version of GCC 10 will be available from ARM which fixes this issue?
Thanks,
Jamie
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: 27 July 2021 10:09
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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 v1.4.0 release started
Hi Jamie,
Can I ask about your toolchain in use?
GNUARM 10-2020-q4-major will cause a similar issue. TF-M suggests to avoid using this version: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti….
Best regards,
Hu Ziji
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: Tuesday, July 27, 2021 4:48 PM
To: Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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: [TF-M] FW: TF-M v1.4.0 release started
Hi Jamie,
Sorry for the trouble.
According to your description, the violation error is caused by non-secure test cases. is it correct?
The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine.
Can you please help narrow the step in which tfm_secure_api_error_handler() is called?
Besides, do you mind trying if IPC model can work on your board?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 3:43 PM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started
Hi,
I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following:
cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on ..
And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core:
Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED
Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED
Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED
Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED
*** End of Secure test suites ***
Security violation when calling secure API
[INF] Starting bootloader
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
Output from non-secure core:
Non-Secure system starting...
#### Execute test suites for the Non-secure area ####
Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)...
> Executing 'TFM_NS_PS_TEST_1001'
Description: 'Set interface'
Non-Secure system starting...
So something that has changed from 1.3 to 1.4 seems to have broken our platform.
Thanks,
Jamie
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: 26 July 2021 09:50
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] TF-M v1.4.0 release started
EXTERNAL EMAIL: Be careful with attachments and links.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
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: Wednesday, July 21, 2021 11:25 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] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
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> On Behalf Of Ken Liu via TF-M
Sent: Monday, August 9, 2021 10:18 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)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,
Shawn is applying stateless handle to built-in services, here are the patches for reviewing:
https://review.trustedfirmware.org/q/topic:%22Apply_stateless_handle%22+(st…
Only those services are really STATELESS can be applied with stateless handle. For the legacy connection-based services (supports multiple sessions), please keep using the connect/call/close based mechanism when accessing services.
Thanks.
/Ken
Hi,
There are a v8.0m re-entrant detecting mechanism inside SPM: 'tfm_spm_validate_caller'. For v8.1-M, it has hardware reentrant detection so it does not need a software solution.
The concept is to let SVC handler check these points to see if a reentrant is happening:
* If the return address is inside of NS Agent partition.
* If the LSB of LR is ZERO.
* Check if stacked frame equals a standard exception frame size.
This mechanism has proven its integrity, but has these shortages:
* It needs an SVC, while SPM are going forward to work under thread mode.
* The frame size checking is complex, we need to take care if NSPE is applying FPU or not, different configurations has different frame size.
Hence I moved this mechanism into NS Agent partition, just the veneer part after SG, by checking if current PSP_S is pointing to a SEAL (We don't use stack before calling into PSA API so stack is totally clear).
I did several times emulation and it looks fine. Now I need your help to review on this part, to see if there are risks on updated mechanism.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11003
Thanks.
/Ken
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
I'd also like to talk about my proposed design for the OTP HAL changes, and get some feedback about provisioning.
This is probably ~30 minutes
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jianliang Shen via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 02 August 2021 04:08
To: Anton Komlev
Cc: nd; tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] 回复: Technical Forum call - August 5
Hi
I want to introduce my recently work to you about TF-M test configuration refinement in the tech forum on August 5th. It may take 15-20 minutes.
Best Regards
Jianliang Shen
发件人: Summer Qin <Summer.Qin(a)arm.com>
发送时间: 02 August 2021 10:57
收件人: Anton Komlev <Anton.Komlev(a)arm.com>
抄送: Jianliang Shen <Jianliang.Shen(a)arm.com>
主题: Re: Technical Forum call - August 5
________________________________
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 <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Wednesday, July 28, 2021 7:23 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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 - August 5
Hi,
The next Technical Forum is planned on Thursday, August 5, 15:00-16:00 UTC (US 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
