June 2019 - TF-M - lists.trustedfirmware.org

by Andrej Butok

Hi Antonio, > TF-M Crypto will align to newest release of Mbed Crypto when they will become available Just FYI: The newest official release of Mbed Crypto is v1.1.0: https://github.com/ARMmbed/mbed-crypto/releases Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- 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…

5 years

2
2
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

5 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…

5 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

5 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

5 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>

5 years, 1 month

1
0
0 0

Re: [TF-M] Feature request

by Gyorgy Szing

Hi Andrej, We shall avoid adding IDE specific workarounds to the code. I see many possible better solutions to this problem: 1. All IDEs are capable to "ignore" files present in the working copy but not part of the build. You could try this feature. 2. Irrelevant files can be deleted from the workspace by using a script. 3. Using a different generator of CMake could allow to generate a project format which your IDE can import. (See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) 4. Using CMAKE_EXPORT_COMPILE_CMMANDS will make CMake to generate a json file listing all C files part of the build with the build command needed to compile them. It could be relative simple to write a Python script to create an IDE project or to update an existing one with build settings. (See: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.…) 5. Long term a generators could be up streamed to CMake to add Support for you IDE. Please contact the IDE vendor with this request. 6. The IDE could be updated to co-operate with "cmake server" to allow integration with cmake based build systems. Again please contact the IDE vendor with this request. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 18 June 2019 08:23 To: Miklos Balint <Miklos.Balint(a)arm.com>; Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Feature request Hi Miklos, One more feature request: 3) Using separate files in TFM without #ifdef is causing issues for IDE projects, and requires creation of separate projects/targets (with different file set) per each feature combination. We are using IDEs (IAR, MCUx, Keil), so we have to add missing #ifdef to the original TFM source code. Please use #if/#ifdef in TFM, everywhere were it is needed. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: Monday, June 17, 2019 5:31 PM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Feature request Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /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: https://eur01.safelinks.protection.outlook.com/?url=www.iar.com&data=02… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: https://eur01.safelinks.protection.outlook.com/?url=www.twitter.com%2Fiarsy… <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…> -- 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… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 1 month

2
2
0 0

[PLEASE READ] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

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

5 years, 1 month

1
0
0 0

TF-M CI Blog

by Shebu Varghese Kuriakose

Hi All, Not sure if everyone knows that there is an initial deployment of TF-M CI (Continuous Integration) system. It tests every patch that gets submitted in TF-M gerrit. Read about the CI system and find the relevant links in this blog - https://www.trustedfirmware.org/blog/trusted-firmware-open-ci-update/ Thanks, Shebu

5 years, 1 month

1
0
0 0

Please help review the patches of architecture abstraction in TF-M

by David Hu (Arm Technology China)

Hi all, Could you please review the following patches to abstract architecture specific code? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157/<https://review.trustedfirmware.org/c/trusted-firmware-m/+/1157> https://review.trustedfirmware.org/c/trusted-firmware-m/+/1158 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1390/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1251/ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1252/ The above patches abstract architecture specific code to decouple TF-M core to specific architecture details. It can help enable TF-M running on diverse Arm M-profile architectures. Other Arm M-profile architecture implementation will be added later. Suggestions are welcome. Thank you. Best regards, Hu Ziji

5 years, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M June 2019