- TF-M - lists.trustedfirmware.org

[RFC]Patches for migrating testing codes from TF-M to tf-m-tests

by Kevin Peng

Hi, As have shared on the tech forum yesterday, there is the activity to move the test codes from tf-m to tf-m-tests. Here are the patches for the step 1 - moving the codes without modifications: https://review.trustedfirmware.org/q/topic:%22Migration_of_test_code%22+(st… Please help on review. Thanks. The review window would be closed in one week in case of no comments. Best Regards, Kevin

5 years, 11 months

1
0
0 0

TF-M: v1.1 and Ecosystem Enablement Blog

by Shebu Varghese Kuriakose

Hi All, Here is a blog about TF-M v1.1 and recent Ecosystem enablement - https://www.trustedfirmware.org/blog/tfm-v1-1-blog/ Regards, Shebu TF-M Technology Manager

5 years, 11 months

1
0
0 0

Re: [TF-M] New TrustedFirmware.org security incident process is now live

by Anton Komlev

Hi, Let me remind you about the security incident process and open registration for Trusted Stakeholders. Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley via TF-M Sent: 30 June 2020 15:13 To: tsc(a)lists.trustedfirmware.org; tf-a(a)lists.trustedfirmware.org; tf-m(a)lists.trustedfirmware.org; op-tee(a)lists.trustedfirmware.org; mbed-tls(a)lists.trustedfirmware.org; mbed-tls-announce(a)lists.trustedfirmware.org; hafnium(a)lists.trustedfirmware.org Subject: [TF-M] New TrustedFirmware.org security incident process is now live Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

5 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - July 23

by Kevin Peng

Hi Anton, I'd like to give a brief introduction on the changes (both happened and proposal) for TF-M testing. The duration would be ~30 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, July 20, 2020 4:14 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 23 Hello, The next Technical Forum is planned on Thursday, July 23 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 11 months

2
1
0 0

New build system WIP

by Raef Coles

Hi all The new buildsystem (work in progress) is now available at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5039. Comment would be very much appreciated. There have been some minor interface changes to how the buildsystem is invoked. a sample invocation is: cmake -S .. \ -B . \ -G"Unix Makefiles" \ -DTFM_PLATFORM=musca_s1 \ -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake \ -DCMAKE_BUILD_TYPE=release -DBL2=ON \ -DNS=ON \ -DTFM_PSA_API=ON \ -DTEST_NS=ON -DTEST_S=ON \ -DTFM_ISOLATION_LVL=2 More specifically cmake -S [Source_dir (often ..)] \ -B [build_dir (often .)] \ -G ["Unix Makefiles" OR Ninja] \ -DTFM_PLATFORM=[musca_b1 OR musca_s1 OR mps2/an521 OR cypress/psoc64 ETC...] -DCMAKE_TOOLCHAIN_FILE=[build_dir/toolchain_GNUARM.cmake OR build_dir/toolchain_ARMCLANG.cmake] -DCMAKE_BUILD_TYPE=[release OR debug OR minsizerel OR relwithdbginfo] -DBL2=[OFF OR ON] -DNS=[OFF OR ON] -DTFM_PSA_API=[OFF OR ON] -DTEST_NS=[OFF OR ON] -DTEST_S=[OFF OR ON] -DTFM_ISOLATION_LVL=[1 OR 2] Note that this interface is not set in stone and may change before these patches are merged. The new buildsystem is currently missing a few of the platforms, as well as some features. All of these are planned to be added prior to merging. Notable are dualcpu/Cypress PSoC64 which is currently being finalized, documentation building, and image signing for some of the boot modes which is on the TODO list. Note that unlike previous versions, this should work "out the box" with regard to dependencies. The paths for dependencies can be set, but some patches to mbedtls that are in the process of being upstreamed are used. These patches are stored in the lib/ext/mbedcrypto directory and can easily be applied manually. Regards, Raef Coles

5 years, 11 months

1
0
0 0

MCUBoot related changes

by Tamas Ban

Hi, Just a heads-up for the coming changes related to MCUBoot. Some of them requires installing new tools in build system others could affect devices on the field (if there is any) after SW upgrade. Short term, within one week: 1. Official imgtool enablement: * The official released version of the image signings script will be used. * Must be installed in the build system. It is a PyPI package: imgtool v1.6 * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4564/6 2. Encrypted image support: * This feature already exists in the upstream repo for a while * This change makes possible to turn it on in TF-M build system * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4565/6 Long term, but still expected in Q3: 1. Removal of forked MCUBoot from TF-M: * Only upstream MCUBoot will supported * Platform and project related files will be kept: i. shim layer to match MCUBoot HAL's to TF-M's HAL ii. bl2_main.c, example signing keys, keys.c iii. platform code: flash and UART drivers, implementation of boot_hal.h * When building TF-M with upstream MCUboot it is a mixture of files from the two repo + crypto code from mbedcrypto repo. * https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4953 * The removal of the fork depends on the feature upstream to MCUBoot repo: i. https://github.com/JuulLabs-OSS/mcuboot/pull/739 ii. RAM_LOAD: PR will come a bit later 1. Removal of LEGACY_TFM_TLV_HEADER support * This is a compatibility mode. It was introduced to hide the difference in the definition of the TLV header int he shared data between bootloader and runtime SPE. * If forked removed, then this is not necessary anymore, unless an forked version of MCUBoot wants to cooperate new SPE. * Please check and indicate if you think that this is a valid use case and compatibility mode must be kept! Tamas

5 years, 11 months

1
1
0 0

TF-M/FreeRTOS blog

by Shebu Varghese Kuriakose

Hi All, Here is a blog post about FreeRTOS/TF-M integration - https://freertos.org/2020/07/security-for-arm-cortex-m-devices-with-freerto… Regards, Shebu

5 years, 11 months

1
0
0 0

TF-M Technical Forum call - July 23

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, July 23 at 6:00-07:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 11 months

1
0
0 0

Process for deprecating and removing platforms

by Soby Mathew

Hi Everyone, The document in tf.org defines the different "Platform Support Life Cycle": https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Although a platform can be implicitly in deprecated state due to lack of support or maintenance, a process to explicitly declare a platform as deprecated with the intention to remove it in future is needed as well. So I have attempted to define a process as described here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4962/1/docs/… Comments welcome. Best Regards Soby Mathew

5 years, 11 months

1
0
0 0

Re: [TF-M] Persistent key storage ownership/access

by Andrew Thoelke

Hi, The ITS design requires that all data items are private to its client - it essentially just provides a persistence capability within the same isolation domain. So it is not possible for two distinct clients to access the same stored material, *unless they do this through a common intermediary*. Jamie outlines one approach: PSA Crypto Partition hosts the key store, and delegates the operations to the AES partition. But this fails the concurrency requirement as noted. Another plausible approach is that the AES Partition is a special/trusted client of the PSA Crypto Partition and uses a dedicated service/API to retrieve the AES client's key material. However, this also fails the concurrency objective when the PSA Crypto Partition is busy. Without the IPC model (which allows for nested/interleaved message handling, under service developer control) - the design that would work is to: 1. Create a key store Partition that interfaces with ITS 2. Have the PSA Crypto and AES partitions be trusted clients of the key store (the key store does not allow other client connections) 3. Key management operations go through a PSA Crypto service, which invokes the key store service to store material in ITS 4. AES operations go through a AES service, which invokes the key store service to retrieve key material This model works, but delivering the desired concurrency requires that the framework supports multiple Partitions, and can run one Partition while another is busy/blocked. Note that the key store service is _just_ a proxy to ITS using the key-id + Crypto-client-id supplied by its client. Security depends on the client-ids of the Crypto and AES Partitions being fixed so that the private key store service can strictly enforce which clients can use it. Regards, Andrew From: psa-crypto <psa-crypto-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via psa-crypto Sent: 10 July 2020 14:22 To: Quach, Brian <brian(a)ti.com>; tf-m(a)lists.trustedfirmware.org; psa-crypto(a)lists.trustedfirmware.org Subject: Re: [psa-crypto] Persistent key storage ownership/access Hi Brian, It is true that each persistent key has only one owner who can access it, the partition that created it. But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own. I think a more expected flow would look like: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID. 3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1. 4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material. But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted. I am adding the psa-crypto mailing list to this, as people on there may have more/better input. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Quach, Brian via TF-M Sent: 10 July 2020 06:18 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Persistent key storage ownership/access Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function and provides the key ID. 3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: * PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: * ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 11 months

2
1
0 0

Re: [TF-M] Persistent key storage ownership/access

by Jamie Fox

Hi Brian, It is true that each persistent key has only one owner who can access it, the partition that created it. But note that even if the driver partition could be given permission to access the key, then it wouldn't immediately fix the issue. The driver partition would then need to implement another layer of access control, otherwise partitions would be able to use it as a conduit to access keys that they don't themselves own. I think a more expected flow would look like: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function in the PSA Crypto partition and provides the key ID. 3. PSA Crypto partition retrieves the key from ITS for use. Client ID = -1. 4. PSA Crypto partition calls an AES crypto function in the driver partition and provides the key material. But I assume you discarded this approach because it didn't give you the level of concurrency between PSA Crypto and the crypto driver that you wanted. I am adding the psa-crypto mailing list to this, as people on there may have more/better input. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M Sent: 10 July 2020 06:18 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Persistent key storage ownership/access Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1. NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2. NS application calls an AES crypto function and provides the key ID. 3. AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: * PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: * ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 11 months

1
0
0 0

Persistent key storage ownership/access

by Quach, Brian

Hi, I see that keys can only be accessed/modified by their owning secure partition. File ID used by ITS is 12-bytes. Assuming the Application imports a persistent key and then opens the key, the File ID would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | DEFAULT_NS_CLIENT_ID (-1) Then the key handle returned from the psa_open_key() is used for any cryptographic operations. This makes perfect sense to me for PSA API v1.0 beta 3. However, for PSA API v1.0 release where open/close key was removed and only the Key ID will be used, I'm confused on how the key access and File ID would work. Initially, when the app imports the key, the key file would have the same 12-byte file ID as the case above. However, when the application calls a cryptographic function, it now provides the 32-bit key ID instead of the handle. The persistent key is not cached and must be read from the ITS. I had assumed the crypto driver would call psa_export_key() to retrieve the key for use, however, the File ID in this case would be: | 32 -bits | 32 -bits | 32 -bits | ========================================== PSA Crypto SP ID | Key ID | Secure Partition ID of Crypto Driver The file ID would not match what the App imported and the key would not be found. Am I misunderstanding how the key should be accessed for use after it has been imported or how the File ID is generated? Another explanation of the scenario if the above was not clear: 1) NS application calls psa_import_key() to store a key with an ID. Key is stored by ITS with client ID of -1 (DEFAULT_NS_CLIENT_ID). 2) NS application calls an AES crypto function and provides the key ID. 3) AES driver crypto function calls psa_export_key() to retrieve the key from ITS for use. Client ID = AES secure partition. RoT Partition 1: - PSA Crypto (with keystore) RoT Partition 2: - AES driver (placed its own partition so other crypto ops in PSA Crypto partition can run in parallel...multiple HW accelerators) RoT Partition 3: - ITS Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

5 years, 11 months

1
0
0 0

TF-M v1.1 release

by Anton Komlev

Hello, Today, TF-M project released version v1.1, tagged by TF-Mv1.1<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.1>. Please take a look into Change Log<https://ci.trustedfirmware.org/view/TF-M/job/tf-m-nightly/lastStableBuild/a…> for the new features and changes. The next and further releases are expected in every 4 months. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M Technical lead Arm Ltd.

5 years, 11 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - July 9

by Summer Qin

Hi Anton, I'd like to give a brief introduction to SPRTL (Secure Partition Runtime Library) update. It will take no more than 30 minutes. Best Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, July 3, 2020 10:44 AM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - July 9 Hi Anton, I’d like to give a brief introduction to Profile Medium design. It won’t take very long time. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, July 2, 2020 6:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 9 Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 11 months

2
1
0 0

C preprocessor directives issue for IAR linker

by Andrej Butok

Hello Tomas, I am trying to port TFM to IAR Embedded Workbench v8.50.5 IDE (NOT cmake) for LPC55S69. And have an error during linking in tfm\platform\ext\common\iar\tfm_common_s.icf on #include "region_defs.h": Error[Lc003]: expected ""check", "define", "do", "export", "if", "include", "initialize", "keep", "place", "reserve", or a placement label It can be fixed by changing: #include "region_defs.h" to: include "region_defs.h"; but it creates 44 Errors [Lc003] in region_defs.h, The IAR linker does not understand the C preprocessor directives like #ifndef, #ifdef, #endif etc. How did you solve this IAR issue? As we have to use IAR IDE (not cmake), what is your suggestion? Maybe a special IAR Linker preprocessing parameter/option? Thank you, Andrej Butok

5 years, 11 months

2
8
0 0

Call for review on TF-M HAL design

by Edison Ai

Hi All, Please review the design of the TF-M HAL: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4076. This new design aims to make the TF-M more simple to integrate and porting to different platforms. The current version only includes the HAL API for the TF-M core, the HAL for Secure Partition will be the next step. Main Context: * There are 6 modules in the Core HAL: * Isolation API: Provides the necessary isolation functionalities required by the PSA FF and TBSA-M, and provides functions to SPM to check the validate of memory access. * Platform API: Provides the platform initial, receives platform data, system reset, etc. * Loader API: Provides the function to load partition and service and provides the necessary data to SPM. * Log dev API: Provides the log system functions. * Interrupt API: Provides the interrupt functions. * Debug API: Provides the debug functions. * There are some sequence diagrams that help you to more quick and easy the using of the new HAL. Main Change: There are some main changes to the TF-M core: * Move most of the platform data from Core to the platform and need tools to support it. * The platform needs to provide the required necessary memory to the Core for its runtime data using. * Load mode change. The platform needs to load the secure partition and provide the necessary info to the core. Please see the design for more details and welcome comments. BR, Edison

5 years, 11 months

1
2
0 0

Re: [TF-M] TF-M v1.1 - Heads up

by Anton Komlev

Hi All, New TF-Mv1.1-RC2 tag has been applied to all project repositories, marking fixes of issues found in RC1. The changes are small so only affected configurations will be retested. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 24 June 2020 18:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.1 - Heads up Hi All, Both trusted-firmware-m and tf-m-tests repositories are tagged with TF-Mv1.1-RC1 tag marking the code freeze and beginning of the release candidate testing. Best regards, Anton Komlev Tech Lead of TF-M in Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 10 June 2020 18:28 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.1 - Heads up Hi All, Just a heads up that TF-Mv1.1 tag is planned for middle to end of July. Code freeze of TF-M master is aimed around end of June to allow enough time for testing. Similar to TF-Mv1.0 and previous tags, v1.1 will include all TF-M changes in TF-M master available till code freeze in end of June. Availability of the tag will be notified via. this mailing list. Thanks, Shebu Technology Manager-TF-M, Arm Ltd.

5 years, 12 months

1
0
0 0

Re: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds

by Jamie Fox

Hi Thomas, This is not expected. Please can you share the error that you see? (Might be best to open an issue on developer.trustedfirmware.org for it) Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 29 June 2020 16:38 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] f58bd227, Build: Disable RAM FS by default, breaks Musca_A builds Looks like f58bd227 breaks Musca_A builds, or at least it will not boot without additional configuration options. Is this expected? Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 12 months

2
3
0 0

Re: [TF-M] TF-M Technical Forum call - July 9

by David Hu

Hi Anton, I'd like to give a brief introduction to Profile Medium design. It won't take very long time. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, July 2, 2020 6:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - July 9 Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

Re: [TF-M] TF-M Technical Forum Agenda - June 25

by Anton Komlev

The below mail was intended to arrive before previous Tech Forum but blocked because of big attachment. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 01 July 2020 13:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum Agenda - June 25 Hi, Please find the presentation materials attached for Secure functions topic. Reminder, the PSA L3 isolation design is here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The best, 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: 25 June 2020 13:38 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 Technical Forum Agenda - June 25 Hello, The agenda for today's forum: * PSA Isolation (level 3) design review * Secure Function model * Any other business, if time permitted. See you soon, 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: 17 June 2020 12:55 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 Technical Forum call - June 25 Hello, The next Technical Forum is planned on Thursday, June 25 at 15:00-16:00 UTC (US time zone). This is exceptional time zone change because of a public holiday in China that day. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

TF-M Technical Forum call - July 9

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, July 9 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

6 years

1
0
0 0

Re: [TF-M] [RFC] PSA Isolation (level 3) design document

by Ken Liu

Someone reported the previous mail is lost in their mailbox due to unknown reasons, let me re-send it. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, June 24, 2020 3:08 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] PSA Isolation (level 3) design document Hi, We have created one PSA Isolation implementation design document and now call for comments: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4730 The overall goal is to cover all isolation levels into this one document, and at current stage we take level 3 as an example. The image layout and regions are based on the assumption of the existing TF-M code base. Feel free to put comments, or post under this task: https://developer.trustedfirmware.org/T778 Thanks. /Ken

6 years

1
0
0 0

[RFC] TF-M Documentation Contribution Format

by Minos Galanakis

Hi, As the project matures, and the community grows, I would like to revive an old discussion and suggest that we set some guidelines for contributing to the project's documentation. I would like to propose that we establish a minimal sub-set of rules, based on the official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most widely used notation. This offers compatibility with existing tools for proofing and producing said documentation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, as long as they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not use more than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). Please refer to the `tfm_sw_requirement.rst<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti…>` as an example 12. No special formatting should be allowed in Headers ( code, underline, strike-through etc ) 13. Long URLs and external references should be placed at the bottom of the page and referenced in the body of the document 14. New introduced terms and abbreviations should be added to Glossary and directly linked by the `:term:` notation across all documents using it. When something new, which is not covered is required, the rule should be first to follow the any reference to of an existing document, and the Python Documentation rules otherwise. Please let me know if you have any questions/objection or proposals or new rules you would like to consider. Any feedback is more than welcome. Minos

6 years

1
0
0 0

New TrustedFirmware.org security incident process is now live

by Dan Handley

Hi all The new TrustedFirmware.org security incident process is now live. This process is described here: https://developer.trustedfirmware.org/w/collaboration/security_center/repor… Initially the process will be used for the following projects: TF-A, TF-M, OP-TEE and Mbed TLS. The security documentation for each project will be updated soon to reflect this change. If you are part of an organization that believes it should receive security vulnerability information before it is made public then please ask your relevant colleagues to register as Trusted Stakeholders as described here: https://developer.trustedfirmware.org/w/collaboration/security_center/trust… Note we prefer individuals in each organization to coordinate their registration requests with each other and to provide us with an email alias managed by your organization instead of us managing a long list of individual addresses. Best regards Dan. (on behalf of the TrustedFirmware.org security team)

6 years

1
0
0 0

[RFC] Profile Medium design document

by David Hu

Hi all, Profile Medium design document has been uploaded for review on https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4775. I'd like to ask for review and comment. Any suggestion is welcome. Thanks in advance for any help. As part of TF-M Profiles, Profile Medium aims to connect devices to cloud services with asymmetric cipher support. Compared to Profile Small, Profile Medium contains more combabilities and requires more resource. Best regards, Hu Ziji

6 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M