- TF-M - lists.trustedfirmware.org

by Kevin Townsend

Hi, I'm currently working on integrating TF-M into Zephyr and getting TF-M working with QEMU. Part of that work is simplifying the setup and build process to generate a TF-M secure library. Was the idea of git submodules for dependencies considered and rejected? Using sub-modules would reduce the number of setup steps required, and pair external dependency versions with specific TF-M commits/releases. There may be a valid reason this approach was rejected, but it seems like a sensible option on the surface? Best regards, Kevin Townsend

6 years, 11 months

1
0
0 0

Re: [TF-M] [PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, The last patch for this task is pushed for review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1487 Please help to review and the 'configs' directory would be the only place for holding configurations. Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, June 25, 2019 2:02 PM > To: TF-M(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] [PLEASE READ] Move configuration files into specified directory > > Hi, > Configurations has been moved into 'configs' directory. Please: > - Update your build commands to build with configurations under 'configs' > directory, check updated document: docs/user_guides/tfm_build_instruction.rst > - If you want to push new configurations, please put new configurations under > 'configs' directory. > > The dummy configurations under root directory will be removed soon so please > DO UPDATE YOUR BUILD COMMAND! > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, June 18, 2019 10:03 AM > > To: TF-M(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Move configuration files into specified > > directory > > > > Hi, > > The patch has been pushed for a while and is going to be merged in one > > week, please help to review it if you planned but still not have a look: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > After this patch get merged, all new configurations created in root > > directory will be rejected. Please create new configuration files under ./configs > directory. > > The existing fake configuration files under root directory will be > > removed after CI setting changed. > > > > Thanks. > > > > -Ken > > > > > -----Original Message----- > > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > > Liu (Arm Technology China) via TF-M > > > Sent: Tuesday, June 11, 2019 1:40 PM > > > To: TF-M(a)lists.trustedfirmware.org > > > Cc: nd <nd(a)arm.com> > > > Subject: [TF-M] [RFC] Move configuration files into specified > > > directory > > > > > > Hi, > > > Since the number of configuration files is increasing, let’s move > > > the configuration files (ConfigXXXX.cmake) into specified directory. > > > This would reduces the files under root directory and makes the > > > structure more clearer. > > > > > > I have created the issue and patch for it: > > > https://developer.trustedfirmware.org/T394 > > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 > > > > > > IMPORTANT NOTES: > > > To be compatible with the existing building configurations, the > > > existing configuration files have been forwarded into the > > > corresponded configuration file under ./configs. Which means there > > > are two set of configuration files under sources tree at current – > > > but this will change soon. There is a warning while you are building > > > with root configurations files: “Please use the configs available in > > > the ./config sub- > > directory.” > > > > > > So please: > > > > > > - If you are planning to create new configuration, create it under > > > ./configs instead of root directory > > > - The reference of configuration files under root directory will be > > > removed soon, please change your build system setting to reference > > > the configuration files put under ./configs > > > > > > Any feedbacks please reply this mail or put comments under the > > > issue, thanks > > > 😉 > > > > > > -Ken > > > > > > -- > > > TF-M mailing list > > > TF-M(a)lists.trustedfirmware.org > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 11 months

1
0
0 0

independent device driver model working along side SPM

by R, Manoj

Hi, Is there a design guideline available for device driver which is working on secure side alongside SPM. I do not want to plug my driver in TF-M due to latency considerations. Basically my plan is to introduce non secure callable veneers for calling the interfaces of the driver which I am introducing. Any thoughts on this will be helpful. Regards Manoj

6 years, 12 months

1
0
0 0

Changes to PSA headers in TF-M

by Jamie Fox

Hi all, I am proposing a couple of changes to the standard PSA headers in TF-M. The first change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1458/ It renames the standard PSA headers in TF-M from psa_<api>.h to psa/<api>.h. TF-M defined headers are not affected. This change also tweaks a large number of #includes across the TF-M repo to use the new names. Any code maintained outside the TF-M repo that includes PSA headers from TF-M will also need to be changed to use the new names in #includes once this is merged. The benefit of this change is that is brings the names of the headers in TF-M into agreement with the names used in the PSA Firmware Framework. It will also make running the PSA API tests easier, as the step of copying the PSA headers to the standard names is no longer required. The second change is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1459/ It adds a copy of the psa/error.h header, which contains new standard error codes intended to be used by the SPM and RoT Services. The "PSA_SUCCESS" and "psa_status_t" definitions are also moved to this header, and it is included by psa/client.h and psa/service.h. This change should have minimal impact on other code -- no code is immediately changed to use the new error codes, but upstreaming the header now allows services to start using the new error codes when needed. Kind regards, Jamie

6 years, 12 months

1
0
0 0

[RFC] Secure Partition Runtime Library

by Ken Liu (Arm Technology China)

Hi, We are now involving secure partition runtime library into tf-m design. While implementing isolation level 2, some runtime APIs (printf e.g.) calling would cause fault, because it is accessing global variables (The STDIO instance) or need to manipulate hardware (UART). So we shutdown calling to these APIs - it is lucky that the secure service logic does not rely on these functions. This leads to the thinking of runtime APIs implementation - not only C runtime mentioned in PSA FF specification, but also developer APIs for service client. These APIs are definitely necessary and need to work well under all isolation levels. Since we cannot put multiple runtime copies into secure partitions (waste and not supported by single firmware linker design), shared runtime library looks like the only choice. Here we introduce the design of a runtime library for secure partition usage. We aligned the concepts with PSA FF and it does not break the mandatory requirements of isolation, and proposes designs for some dedicated APIs. I know there may be similar runtime implementations somewhere, while I just want to implement the functions quick to make out a solution before other library searching and investigating stage (which may spent quite much time). The key requirements of this runtime library are: - This library is protected as Read-Only + executable by MPU, so all other data will not be included into protected region. This point is very important. - For those session/handle based API set, necessary supporting from tooling or other parts needs to be involved. Please help to review the design document at: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1425 Feel free to add you as reviewers and comment something; and you can reply to this thread, too. Any new thinking is worthy of being discussed. Thanks. -Ken

7 years

1
0
0 0

Attestation token verifier

by Tamas Ban

Hi, You can find here a useful script which can be used to verify an initial attestation token(IAT) on server side when it is retrieved from the IoT device: https://developer.trustedfirmware.org/T411 BR, Tamas

7 years

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Andrej Butok

Hi Antonio, Sorry, ignore the previous e-mail. Yes, tfm_mbedcrypto_include.h was mixed up with tfm_mbedcrypto_config.h -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, June 27, 2019 12:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] tfm_mbedcrypto_include.h Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

7 years

1
0
0 0

Re: [TF-M] tfm_mbedcrypto_include.h

by Antonio De Angelis

Hi Andrej, tfm_mbedcrypto_include.h is a file which is private to TF-M Crypto service and it's ok for it to be included directly by the service modules. I think what you are referring is platform/ext/common/tfm_mbedcrypto_config.h, which is indeed the configuration of the Mbed Crypto library (similar to what was done with the configuration of the Mbed TLS library), and as far as I can see is not included directly by any module. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 June 2019 11:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tfm_mbedcrypto_include.h Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

7 years

1
0
0 0

tfm_mbedcrypto_include.h

by Andrej Butok

Hello, The following TFM files contain direct include of tfm_mbedcrypto_include.h", which may cause conflict with a platform/project-specific mbed-crypto configuration: \secure_fw\services\crypto\crypto_aead.c(16) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_alloc.c(11) \secure_fw\services\crypto\crypto_cipher.c(16) \secure_fw\services\crypto\crypto_generator.c(16) \secure_fw\services\crypto\crypto_hash.c(16) \secure_fw\services\crypto\crypto_key.c(16) \secure_fw\services\crypto\crypto_init.c(8) \secure_fw\services\crypto\crypto_mac.c(16) Guess, it have to be replaced by: #if !defined(MBEDTLS_CONFIG_FILE) #include "tfm_mbedcrypto_include.h" #else #include MBEDTLS_CONFIG_FILE #endif As it is used by mbed-crypto and previous version of TFM. Thanks, Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

7 years

1
0
0 0

Experimental IAR support

by Thomas Törnblom

Thank you for merging my cleanup in T398. I have a set of IAR build related files that I would like to push, both new and modified cmake files and startup and linker scripts for the Musca A board. There is still some work needed on the linker scripts to get everything fully functional but I can load and debug the secure and non secure images, and the non-secure image will start and execute the idle thread. I have not tested mcuboot although it appears to build properly. We have chip vendors that are eagerly awaiting our port and I would like to push this as "experimental". Would this be OK? /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>

7 years

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M