Hi Ken,
I tested with 2.0.0 release. There are my conclusions.
tfm_arch_set_context_ret_code set result (for psa_wait, ...) by using SP stored in sp member of context_ctrl_t structure. It means that before calling tfm_arch_set_context_ret_code TF-M should update SP for thread (partition).
thrd_next update result by calling tfm_arch_set_context_ret_code, if query_state_cb (pointing to query_state implemented by backend_ipc.c) returns THRD_STATE_RET_VAL_AVAIL. For all partition except active (interrupted by PendSV) context (values in context_ctrl_t) is correct. But context is invalid for active partition, because it is updated by PendSV after exit from ipc_schedule and thrd_next.
As result call for psa_wait would fail if some secure IRQ will update signals_asserted after tfm_spm_partition_psa_wait and before PendSV will call thrd_next. SLIH interrupt can assert such signal (call to backend_assert_signal) in spm_handle_interrupt.
I made a simple fix:
diff --git a/secure_fw/spm/core/backend_ipc.c b/secure_fw/spm/core/backend_ipc.c
index 3a968a3..c8b0742 100644
--- a/secure_fw/spm/core/backend_ipc.c
+++ b/secure_fw/spm/core/backend_ipc.c
@@ -454,9 +454,14 @@
/* Protect concurrent access to current thread/component and thread status */
CRITICAL_SECTION_ENTER(cs);
- pth_next = thrd_next();
p_curr_ctx = (struct context_ctrl_t *)(CURRENT_THREAD->p_context_ctrl);
+ /* Update SP for current thread, so tfm_arch_set_context_ret_code can use up to date
+ * value of stack context to return value via R0.*/
+ p_curr_ctx->sp = __get_PSP() - sizeof(struct tfm_additional_context_t);
+
+ pth_next = thrd_next();
+
AAPCS_DUAL_U32_SET(ctx_ctrls, (uint32_t)p_curr_ctx, (uint32_t)p_curr_ctx);
p_part_curr = GET_CURRENT_COMPONENT();
Regards,
Roman.
From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Wednesday, November 8, 2023 22:22
To: Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd(a)arm.com<mailto:nd@arm.com>
Subject: [TF-M] Re: Scheduling bug
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi Ken,
I was using 1.8.0 Release
Looks like this issue was fixed in new design although we would like to test it and confirm this when we migrate to newest release.
We will get back on this to you.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
From: Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Tuesday, November 7, 2023 03:58
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] Re: Scheduling bug
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi Bohdan,
Can you share us the version you are working on?
Looks like the patch is based on a previous version of TFM, and this issue is resolved in the latest code base.
The reason to do such abstraction is just because of such similar issues - the logic was coupled tightly because of synching the partition status, thread status and context update which caused maintenance confusion and effort. And we refactored this part to decouple the logic:
SPM: Add STATUS_NEED_SCHEDULE to manage scheduler (21054) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21054>
Hope this helps, thanks.
/Ken
From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Monday, November 6, 2023 10:01 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Scheduling bug
Hi
There seem to be scheduling bug we have found in SPM.
This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition.
Steps to reproduce:
1. Call psa_wait() from partition (e.g. mailbox partition)
2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this )
3. Following sequence happens:
* Mailbox IRQ has lower priority than SVC thus SVC is not preempted.
* SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending)
* SVC triggers pendSV
i. Mailbox IRQ and pendSV are both pending
* Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed
* Mailbox IRQ calls spm_handle_interrupt
i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called
ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV)
* Mailbox IRQ return, pendsv is started and it runs mailbox partition
i. Mailbox partition has 0 as signal because return value was written to wrong location is stack
Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix(
Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...)
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1).
2. It requests PSA API (for example psa_call).
3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm).
4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread).
5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged).
6. SPM thread is interrupted by FLIH IRQ.
7. FLIH IRQ handler calls spm_handle_interrupt.
8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler.
9. FLIH handler is executed.
10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler.
11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6.
12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards,
Roman.
Hi,
It appears that ITS encryption would be required for PSA Certified Level 3. I'm seeing that this would required a platform specific HAL implementation. Is there some reason PSA Crypto APIs were not used like they were for attestation?
Encryption in ITS
=================
The ITS can optionally be configured to encrypt the internal trusted storage
data.
To support encryption in ITS the target platform must provide an
implementation of the APIs defined in ``platform/include/tfm_hal_its_encryption.h``::
enum tfm_hal_status_t tfm_hal_its_aead_generate_nonce(uint8_t *nonce,
const size_t nonce_size);
enum tfm_hal_status_t tfm_hal_its_aead_encrypt(
struct tfm_hal_its_auth_crypt_ctx *ctx,
const uint8_t *plaintext,
const size_t plaintext_size,
uint8_t *ciphertext,
const size_t ciphertext_size,
uint8_t *tag,
const size_t tag_size);
enum tfm_hal_status_t tfm_hal_its_aead_decrypt(
struct tfm_hal_its_auth_crypt_ctx *ctx,
const uint8_t *ciphertext,
const size_t ciphertext_size,
uint8_t *tag,
const size_t tag_size,
uint8_t *plaintext,
const size_t plaintext_size);
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi All,
Since ST platform seems to be supported only passively, I try to adapt tf-m
for the new ST U5Axx and U5Gxx MPUs with 4MB flash on my own.
It does not come easy since some things are hardcoded and new HAL version is
required while breaking HAL changes have been introduced, but this is not
the reason why I make this post.
Is there any easy way, I mean, some cmake switch, which would allow for a
full rebuild without redownloading the required packages?
Since clean rebuild from scratch takes time and I need to do it frequently
while my Internet connection currently is not super-fast and stable such
option would be the most helpful.
Kind regards,
Tomasz
Hello Bohdan
The PSA token spec v2.0 is still in draft and hence is not yet supported by the psa-arch-tests.
I am not aware of the specific plan/timelines, but could you please contact psa-arch-tests team to know details?
Best Regards,
Maulik
________________________________
From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org>
Sent: 27 February 2024 12:00 AM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: TF-M Digest, Vol 64, Issue 12
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
tf-m-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
tf-m-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: Attest token v2.0 in psa-arch-tests
(Bohdan.Hunko(a)infineon.com)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Feb 2024 10:50:38 +0000
From: <Bohdan.Hunko(a)infineon.com>
Subject: [TF-M] Re: Attest token v2.0 in psa-arch-tests
To: <tf-m(a)lists.trustedfirmware.org>
Cc: Kostiantyn.Tkachov(a)infineon.com, Roman.Mazurak(a)infineon.com,
Hennadiy.Kytsun(a)infineon.com
Message-ID: <be7dcff9aa504e3f894b7f4fd263512d(a)infineon.com>
Content-Type: multipart/alternative;
boundary="_000_be7dcff9aa504e3f894b7f4fd263512dinfineoncom_"
Hi all,
Any updates on this?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, February 19, 2024 15:24
To: tf-m(a)lists.trustedfirmware.org
Cc: Tkachov Kostiantyn (CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com>; Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Kytsun Hennadiy (CSS ICW SW FW 3) <Hennadiy.Kytsun(a)infineon.com>
Subject: [TF-M] Attest token v2.0 in psa-arch-tests
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi all,
I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them.
Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it.
Am I correct that psa-arch-tests does not support v2.0 of attest token?
If yes, then how do I select v2.0 of attest token?
If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi all,
I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them.
Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it.
Am I correct that psa-arch-tests does not support v2.0 of attest token?
If yes, then how do I select v2.0 of attest token?
If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`.
Per-partition files done:
CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message):
Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
target architecture is known. Please enable at least one language before
including GNUInstallDirs.
Call Stack (most recent call first):
build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
