Hi everyone,
While looking through TFM code I have noticed that tfm_arch_is_priv() is defined for v6 and v7 in secure_fw/spm/cmsis_psa/arch/tfm_arch_v6m_v7m.h but not defined for v8.
Also tfm_arch_v6m_v7m.h is located in secure_fw/spm/cmsis_psa/arch/ folder, while tfm_arch_v8m.h is located in secure_fw/spm/include/.
I think that tfm_arch_is_priv() should also be defined for v8 and also tfm_arch_v6m_v7m.h should be moved to secure_fw/spm/include/. If file will be moved then we can clean up some target_include_directories() which used secure_fw/spm/cmsis_psa/arch/ folder.
Any thoughts 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>
Hi Kevin,
Thanks for your instruction.
We're developing an application RoT partition which access a sensor via an
SPI interface(Based on RA6M4_EK development board). After commands have
been transferred to the sensor,
an SPI_TX_INTERRUPT should be triggered, then calls spi_tx_isr().
Now let's put aside binding secure interrupts to each secure partition,
just talk about how to enable SPI interrupts in secure world simply.
Here is my implementation:
1.Configure this SPI peripheral as secure peripheral.
2.Assign SPI tx and rx interrupts to secure state by setting NVIC->ITNS
register.
3.Enable SPI tx and rx interrupts by seeting NVIC->ISER register.
But during debug, I found that spi0_tx_isr() (The ISRs are also placed
under this application RoT partition's folder) has never been triggered.
Is there anything that I miss?
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
2022/05/17 09:45
Please respond to
Kevin Peng <Kevin.Peng(a)arm.com>
To
Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org"
<tf-m(a)lists.trustedfirmware.org>
cc
Subject
[TF-M] Re: Enable SPI interrupt in secure partition
Hi Poppy,
First-Level Interrupt Handling (FLIH) should be recommended in your use
case as you have latency requirements.
Here is an example:
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui…
You’ll firstly need to add an “irq” item in the manifest and “handling
” it with “FLIH”:
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui…
And also add the “mmio_regions” item with the associated device (SPI) to
give access permissions to the Secure Partition.
The IRQ handling should be in the Secure Partition:
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui…
Note that, no PSA APIs are allowed in the handling.
Best Regards,
Kevin
From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Monday, May 16, 2022 5:38 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Enable SPI interrupt in secure partition
Hi experts,
Recently we're developing a demo based on TF-M, this demo involves using
SPI module to drive a sensor by sending commands in a secure partition.
And we need to enable SPI receive and send interrupt in this secure
partition and the latency shall be as small as possible. I am wondering
how to implement this secure interrupts. Is there any example code or
instrucstions?
Thanks.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi experts,
Recently we're developing a demo based on TF-M, this demo involves using
SPI module to drive a sensor by sending commands in a secure partition.
And we need to enable SPI receive and send interrupt in this secure
partition and the latency shall be as small as possible. I am wondering
how to implement this secure interrupts. Is there any example code or
instrucstions?
Thanks.
Best Regards,
Poppy Wu
吴偏偏
Macronix Microelectronics (Suzhou) Co.,Ltd
旺宏微电子（苏州）有限公司
http://www.mxic.com.cn
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
Hi TF-Mers,
There are several versions of mem* API set in the system.
At the very beginning, the whole secure firmware was put in the library model, and it is expected to be self-contained -- at least at the source level as the first step. Hence a 'tfm_mem*' API set is created for secure firmware usage. The same reason for involving 'spm_mem*' in the PSA compliance model.
When we designed HAL for SPM, we noticed that SPM HAL actually run in the same domain as SPM, hence we encouraged developers to use 'spm_mem*' in SPM HAL.
This brings a bit of difficulty, especially when the platform sources are shared for multiple targets, while other targets do not have 'spm_mem*' API.
As 'mem*' is actually common enough (as they are fundamental API of libc), hence redefine the name is applicable only a system is highly self-contained. In our case, using 'mem*' API can bring much convenience. Hence I am thinking to let sources other than SPM use 'mem*' API, they are platform, partitions and runtime libraries. For SPM sources (under secure_fw/spm), a source-level 'spm_mem*' is kept, to keep the possibility to make SPM itself really self-contained. Now it is only source-level because 'spm_mem*' is actually forwarded to 'mem*'.
I am creating a patch to change this, and want to know your opinion.
Thanks.
/Ken
Hi,
Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists?
I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155>.
In the patch the support of environment variables in manifest lists is removed<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/tool…>.
Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/secu…> surrounded with "@") with their values.
While configure_file does not recognize environment variables.
If you do have environment variables in manifest list, there is an alternative:
Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs.
Best Regards,
Kevin
Hi all,
I'd like to cancel tech form in May 12 due to empty agenda.
Best regards,
Hu Ziji
From: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 5, 2022 2:11 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - May 12
Hi,
(On behalf of Anton)
The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West 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,
Hu Ziji
Hi,
the initial attestation token implementation is aligned with this specification:
https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05
This spec is still evolving and there is a newer version which changes the key values of the claims in the token:
https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html%23t…>
This can cause combability issues between token issuer (device) and token verifier (some remote verification service).
This is an ABI change between token issuer and consumer.
The breaking effect would be manifest in unaccepted IAT tokens by the verifier.
On-device side I see these options to make the transition:
- A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after.
- Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there.
- Keeping the support for both ranges for the long term and letting users choose by build time.
Please share your thoughts on:
- Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility?
- From the above list which option would you vote to support the transition?
Best regards,
Tamas Ban
Hi,
In one of the past tech forums, we claimed that we don't encourage contribution in common logic in assembly, and one of the patches was abandoned because of this. That patch is designed to improve the memset/memcpy performance.
We override these APIs in general because we want the code can be auditable. Then we provided implementations in C, but it shows these implementation does not provide good performance. We want to apply the toolchain provided versions, and looks GNU tool provides the straightest 'byte-copy' version. And armclang involves unnecessary variants which increase the code size a little (not big).
Hence we provide a version with 'tiny' optimization in assembly and mark this patch an exception to the review guidelines, as these under-layer functions won't get changed frequently. We are also seeking an ideal way to apply toolchain versions.
The patch is here for your review:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13735
Thanks.
/Ken
Hello all,
I wanted to let you know that I made the PR which adds encryption on ITS files using the methodology that we discussed before. The encryption is happening in a transparent way for the user, and I tried to avoid major changes in the ITS filesystem. Please add yourself as a reviewer and provide feedback if you think that this is an interesting use case for you.
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096
Regards,
Georgios Vasilakis
Hi,
(On behalf of Anton)
The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West 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,
Hu Ziji
