- TF-M - lists.trustedfirmware.org

by Antonio De Angelis

Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://developer.trustedfirmware.org/), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://developer.trustedfirmware.org/T428 As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Jamie Fox

Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://developer.trustedfirmware.org/), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://developer.trustedfirmware.org/T428 As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- 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

6 years, 9 months

2
1
0 0

Rust implementation of the Armv8-M Security Extension

by Juan Leni

Hi Hugues / Nicolas, Having Rust/LLVM support would be ideal! Juan > Hi Nicolas, > > Thanks for your mail. > From the four LLVM patches needed described in [1], the first one (L1) has landed upstream [2]. Regarding the other ones and your other questions, we are waiting for more information and we will keep you updated as soon as possible. > > Kind regards, > Hugues > > [2] https://reviews.llvm.org/D59888 > > -----Original Message----- > From: TF-M <tf-m-bounces at lists.trustedfirmware.org <https://lists.trustedfirmware.org/mailman/listinfo/tf-m>> On Behalf Of Nicolas Stalder via TF-M > Sent: 30 August 2019 12:25 > To: tf-m at lists.trustedfirmware.org <https://lists.trustedfirmware.org/mailman/listinfo/tf-m> > Subject: [TF-M] Rust implementation of the Armv8-M Security Extension > > Hi > > My company SoloKeys produces open source FIDO2 security tokens (USB + NFC), and we're in the process of a) moving to a Cortex-M33 microcontroller, and > b) an implementation in Rust. > > This is mostly to say that we're very interested in the security extensions [1] landing in LLVM, so embedded Rust can eventually use them, I understand Hugues de Valon from Arm has done some exploratory work on this. > > What is the status of this upstreaming process, are there any road blocks, and is there any ETA on public availability? > > Regards, > Nicolas Stalder > SoloKeys > > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/131358.html > -- > TF-M mailing list > TF-M at lists.trustedfirmware.org <https://lists.trustedfirmware.org/mailman/listinfo/tf-m> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Andrej Butok

Hi Robert, Great! I gave up to convince about the first point https://developer.trustedfirmware.org/T428 As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 9 months

1
0
0 0

TF-M / CMSIS-Pack Alignment

by Robert Rostohar

Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409/7/platform/e… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1409/7/app/main_n… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] http://www.keil.com/pack/doc/CMSIS/Pack/html/index.html [2] http://www.keil.com/pack/doc/CMSIS/Core/html/using_pg.html [3] http://www.keil.com/pack/doc/CMSIS/Driver/html/group__usart__interface__gr.… [4] http://www.keil.com/pack/doc/CMSIS/Driver/html/driverValidation.html IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 9 months

1
0
0 0

Re: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py

by Tamas Ban

Hi all, The following change requires a change in TF-M SW requirements: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1695/ The reason of the change to replace the currently used Python crypto library(pycrypto and pycryptodome) to an actively maintained crypto library (cryptography). CI was already updated. BR, Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 31 July 2019 16:28 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Outdated pycrypto dependency in BL2's imgtool.py Hi, As part of an effort to enable automatic builds of TF-M in Zephyr, I've been trying to get the TF-M + Zephyr S/NS images building and passing on Zephyr's CI system. The only missing requirements for building TF-M in a clean Zephyr SDK 0.10.1 based environment is the pycrypto module, which is used in the imgtool.py utility, specifically: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/bl2/ext/mcuboot… My concern is that this module is no longer actively maintained (last release was 2013!), and it seems like a poor decision to rely on something that isn't actively maintained when more recent alternative are available. Is there a specific reason to keep this module in the script in favour of something more modern? Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Reducing the stack usage of the dummy NV counters implementation

by Jamie Fox

Hi all, While optimising SST stack usage, we found that we were blocked from reducing it further by the stack usage of the dummy NV counters implementation used by all of the development platforms currently maintained in the repo. SST makes calls to the NV counter interface, so any stack used by this implementation gets allocated from the SST stack. The current dummy NV counter implementation reads the entire flash sector containing the counters (generally 4KB) into stack memory, so that it can erase the sector and then re-write the same sector with a counter incremented. It needs to do this because the sector might contain some other data, unrelated to NV counters. I am proposing that we simplify this dummy implementation to assume that the dummy NV counters are the only thing in the sector. Then only the NV counters themselves (currently 28 bytes) need to be read into memory for modification. The downside of this of course is that a whole 4KB flash sector needs to be set aside for the dummy NV counters. This seems bad, but it is worth bearing in mind that this is only a dummy implementation that should never be deployed in a real system. In practice, it seems unlikely to me that we would ever want to make use of the partial-sector left after the dummy NV counters anyway, and no platform currently does. With this change made, the stack allocated for SST can be reduced from 6KB to 2.5KB (in this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/1775). The change is currently on review here https://review.trustedfirmware.org/c/trusted-firmware-m/+/1918/ Feedback and alternative ideas are welcome 😊 Kind regards, Jamie

6 years, 9 months

1
0
0 0

Re: [TF-M] CI

by Shebu Varghese Kuriakose

+ TF-M mailing list... Regards, Shebu -----Original Message----- From: Shebu Varghese Kuriakose Sent: Friday, September 6, 2019 11:17 AM To: Thomas Törnblom <thomas.tornblom(a)iar.com> Cc: nd <nd(a)arm.com>; Ryan Arnold <ryan.arnold(a)linaro.org>; scott.bambrough(a)linaro.org; Bill Fletcher <bill.fletcher(a)linaro.org> Subject: RE: [TF-M] CI Hi Thomas. The TF-M CI - https://ci.trustedfirmware.org/ has been out together by Linaro Infrastructure team funded by trutedfirmware.org Adding your tool chain to the CI might be something you can work with Linaro in the next set of CI enhancements that is being planned. I am copying Linaro team so that they are aware of the request. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, September 6, 2019 7:36 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] CI Who do I talk to about adding our toolchain to the CI build setup? Cheers, /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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

CI

by Thomas Törnblom

Who do I talk to about adding our toolchain to the CI build setup? Cheers, /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>

6 years, 9 months

1
0
0 0

Re: [TF-M] feature-twincpu, unable to configure & build

by David Hu (Arm Technology China)

Hi Thomas, The twincpu branch is running well on PSoC 6 in *IPC model*. Please try the configs with IPC model enabled. For more details and commands, please refer to the document suggested by Chris. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Friday, September 6, 2019 2:11 AM To: Thomas Törnblom <thomas.tornblom(a)iar.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] feature-twincpu, unable to configure & build Hi Thomas, Are you building from the master branch or feature-twincpu? I'm assuming the latter because psoc6 support hasn't yet made it back to the master branch. Which config(s) did you try to build? The feature-twincpu branch is being built pretty regularly for psoc6 (with both clang and gcc), so it should work. There's a document at platform/ext/target/psoc6//cypress_psoc_6_spec.rst detailing exactly how to build. If you can send the details of exactly what commands you're executing and what results you're getting, somebody should be able to help. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: Thursday, September 5, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] feature-twincpu, unable to configure & build > > I have been tasked with making the twincpu feature work with the IAR > toolchain, and I started out trying to build it with clang and gcc but > it seems there's some issues with it. > > I tried using the psoc6 target, but it appears that none of the v6/v7 > targets are supported in configs/ConfigDefault.cmake. If I add that > the build then fails with a complaint about "Armv6-M/Armv7-M can only > support multi-core TF-M now." from tfm_arch_v6m_v7m.h, due to > TFM_MULTI_CORE_TOPOLOGY not being set, but that appears to be set in > one of the cmake files so I guess something is currently broken. > > Is this a known issue and is there are known fix? > > /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> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 9 months

2
1
0 0

Re: [TF-M] feature-twincpu, unable to configure & build

by Christopher Brand

Hi Thomas, Are you building from the master branch or feature-twincpu? I'm assuming the latter because psoc6 support hasn't yet made it back to the master branch. Which config(s) did you try to build? The feature-twincpu branch is being built pretty regularly for psoc6 (with both clang and gcc), so it should work. There's a document at platform/ext/target/psoc6//cypress_psoc_6_spec.rst detailing exactly how to build. If you can send the details of exactly what commands you're executing and what results you're getting, somebody should be able to help. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: Thursday, September 5, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] feature-twincpu, unable to configure & build > > I have been tasked with making the twincpu feature work with the IAR > toolchain, and I started out trying to build it with clang and gcc but it seems > there's some issues with it. > > I tried using the psoc6 target, but it appears that none of the v6/v7 targets > are supported in configs/ConfigDefault.cmake. If I add that the build then > fails with a complaint about "Armv6-M/Armv7-M can only support multi-core > TF-M now." from tfm_arch_v6m_v7m.h, due to > TFM_MULTI_CORE_TOPOLOGY not being set, but that appears to be set in > one of the cmake files so I guess something is currently broken. > > Is this a known issue and is there are known fix? > > /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> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 9 months

1
0
0 0

feature-twincpu, unable to configure & build

by Thomas Törnblom

I have been tasked with making the twincpu feature work with the IAR toolchain, and I started out trying to build it with clang and gcc but it seems there's some issues with it. I tried using the psoc6 target, but it appears that none of the v6/v7 targets are supported in configs/ConfigDefault.cmake. If I add that the build then fails with a complaint about "Armv6-M/Armv7-M can only support multi-core TF-M now." from tfm_arch_v6m_v7m.h, due to TFM_MULTI_CORE_TOPOLOGY not being set, but that appears to be set in one of the cmake files so I guess something is currently broken. Is this a known issue and is there are known fix? /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>

6 years, 9 months

1
0
0 0

T398/T413: Source cleanup and tool integration

by Thomas Törnblom

I have just pushed the latest commit for the source cleanup and IAR integration. -- *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>

6 years, 10 months

1
0
0 0

Re: [TF-M] Updated support for IAR toolchain, T398/T413

by Ken Liu (Arm Technology China)

Hi Thomas, If the topic is quite same, you can re-use the existing item. In other case please create a new one. If the existing item is resolved, you can re-open it with some comments (The history will show the status change of this task, keep same topic in one task makes an easy tracking). Thanks. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas > Törnblom via TF-M > Sent: Friday, August 23, 2019 6:41 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Updated support for IAR toolchain, T398/T413 > > I have done some more cleanup on a later version of TF-M, which I started in > T398 and T413. > > Should I submit a new task or should I refer to these tasks in my commit? > > /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> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 10 months

1
0
0 0

Re: [TF-M] Rust implementation of the Armv8-M Security Extension

by Hugues De Valon

Hi Nicolas, Thanks for your mail. From the four LLVM patches needed described in [1], the first one (L1) has landed upstream [2]. Regarding the other ones and your other questions, we are waiting for more information and we will keep you updated as soon as possible. Kind regards, Hugues [2] https://reviews.llvm.org/D59888 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Nicolas Stalder via TF-M Sent: 30 August 2019 12:25 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Rust implementation of the Armv8-M Security Extension Hi My company SoloKeys produces open source FIDO2 security tokens (USB + NFC), and we're in the process of a) moving to a Cortex-M33 microcontroller, and b) an implementation in Rust. This is mostly to say that we're very interested in the security extensions [1] landing in LLVM, so embedded Rust can eventually use them, I understand Hugues de Valon from Arm has done some exploratory work on this. What is the status of this upstreaming process, are there any road blocks, and is there any ETA on public availability? Regards, Nicolas Stalder SoloKeys [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/131358.html -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 10 months

1
0
0 0

adding an option to run code from RAM

by Andrei Narkevitch

Hello, I'm proposing to add an option to support code execution from device RAM. Basically, it comes to defining a new TFM_RAM_CODE SRAM region in gcc and clang linker scripts for code with .*_ramfunc attribute. This region is intended for privileged secure code running from SRAM. With this, whenever you define an attribute e.g. my_ramfunc, this function will be placed into SRAM instead of Flash. An example: _attribute__((section("my_ramfunc"))) void my_function(void) {}; Implementation: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1815 thanks, Andrei This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 10 months

1
0
0 0

[RFC] SPRTL (Secure Partition Runtime Library) design document update

by Ken Liu (Arm Technology China)

Hi All, There is a tiny update of SPRTL design document: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1886 Fixed a typo, added another security requirements for comparison APIs. Please help to review, thanks. /Ken

6 years, 10 months

1
0
0 0

Re: [TF-M] mcuboot and blob addresses

by Tamas Ban

Hi Thomas, You can find the memory map in: - platform/ext/target/<TARGET>/partition/flash_layout.h Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 02 September 2019 17:07 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] mcuboot and blob addresses I've been trying to find out where the tf-m payload is supposed to be stored at. In tfm_secure_boot.rst I see a memory map for the AN521, but where do find this for the Musca A, which I'm using? /Thomas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 10 months

1
0
0 0

mcuboot and blob addresses

by Thomas Törnblom

I've been trying to find out where the tf-m payload is supposed to be stored at. In tfm_secure_boot.rst I see a memory map for the AN521, but where do find this for the Musca A, which I'm using? /Thomas

6 years, 10 months

1
0
0 0

Rust implementation of the Armv8-M Security Extension

by Nicolas Stalder

Hi My company SoloKeys produces open source FIDO2 security tokens (USB + NFC), and we're in the process of a) moving to a Cortex-M33 microcontroller, and b) an implementation in Rust. This is mostly to say that we're very interested in the security extensions [1] landing in LLVM, so embedded Rust can eventually use them, I understand Hugues de Valon from Arm has done some exploratory work on this. What is the status of this upstreaming process, are there any road blocks, and is there any ETA on public availability? Regards, Nicolas Stalder SoloKeys [1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/131358.html

6 years, 10 months

1
0
0 0

Re: [TF-M] [RFC] Code restructure of core/spm

by Ken Liu (Arm Technology China)

Two more patches added under this topic: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1836 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1837 BR /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: Thursday, August 15, 2019 3:15 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Code restructure of core/spm > > Hi, > The first patch for moving header files is ready at: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561 > Comments are welcome. I had thought to push patches together but looks like it > would block other patches for a while to show a neat merged list, so I would > push them one by one. > > Will keep you update when incoming patches are ready. > > BR > > /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: Thursday, August 1, 2019 11:12 AM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Code restructure of core/spm > > > > Hi, > > > > Several patches for code restructure is coming. Before I post the > > gerrit items, I want to collect your feedback on this. These changes contain: > > > > - Move header files into dedicated directory for easy include, and > > clean the included headers in sources; > > - Change some files' name to let them make more sense. > > - Move SPM related files into 'spm' folder instead of putting them in 'core'. > > - Move some interface files into 'ns_callable' since they are interfaces. > > - Remove 'ipc' folder after all files in it are well arranged. > > > > I will try to do these patches together so they can be merged together. > > But before that I want to request for comments about this, feel free > > to reply in this thread or comment on the task (add yourself if you > > are missing as > > subscribers): > > https://developer.trustedfirmware.org/T426 > > > > BR > > > > /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

6 years, 10 months

1
0
0 0

Removing legacy veneer support from TF-M library model

by Mate Toth-Pal

Hi All, I'm planning to remove the custom veneer support for Library model from TF-M. Please see the proposed patch here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1597/ Ticket for the change is: https://developer.trustedfirmware.org/T439 After this change all secure services must use the automatically generated veneer functions in 'interface/include/tfm_veneers.h', as it is described in the design: https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… This change doesn't affect the NSPM secure functions ('TZ_.*()' and 'tfm_register_client_id()' ). This change also doesn't affect IPC model at all (i.e. psa api functions). Regards, Mate

6 years, 10 months

1
0
0 0

Updated support for IAR toolchain, T398/T413

by Thomas Törnblom

I have done some more cleanup on a later version of TF-M, which I started in T398 and T413. Should I submit a new task or should I refer to these tasks in my commit? /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>

6 years, 10 months

1
0
0 0

[RFC] RE: Build system changes for dual core platforms

by Ken Liu (Arm Technology China)

Hi, These patches are based on an old patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1686 and the task: https://developer.trustedfirmware.org/T199 The existing idea is, app needs v8m veneer to go on the building, so make 'secure_fw' as sub-project of 'app'. While Dual-core is involved, this hierarchy does not make sense. 'secure_fw' should be a standalone sub-project of 'tfm' instead of 'app'. This would benefit the coming build configuration changes. This patch has been put in master branch for quite a while and now call for review again, since in feature branch it has been merged and verified for quite a long time. Thanks. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrei > Narkevitch via TF-M > Sent: Thursday, August 15, 2019 2:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Build system changes for dual core platforms > > Hi, > > Please review the proposed build system changes. Intention of those is to lay > groundwork for building TFM for dual core platforms (aka twincpu). > The main problem of the existing build system is that it assumes that both tfm_s > and tfm_ns run on the same core. In dual core systems secure and non-secure > code runs on two independent cores. Each CPU core can be different in terms of > architecture, configuration etc, and this adds the requirement of separating out > secure and non-secure builds.. > The patches basically do the following: > > * Introduce TFM_MULTI_CORE_TOPOLOGY, that distinguish single core and > multicore builds. > * Split secure and non-secure builds and build both in single building execution. > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1747 > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1748 > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1749 > > Thanks, > Andrei > > This message and any attachments may contain confidential information from > Cypress or its subsidiaries. If it has been received in error, please advise the > sender and immediately delete this message. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 10 months

1
0
0 0

Re: [TF-M] Debugger setup for MPS2+ AN521

by Jamie Fox

Hi Kevin, I don't know much about JLink so cannot help with setup, but there is a quick workaround if reset does not work: insert a "B ." instruction on the first line of the reset handler in the startup file. Then the target will sit in an infinite loop while you connect with the debugger, and afterwards you can use the debugger to increment the PC by two to step over the instruction. The typical debug setup in the TF-M team is to use either a Keil ULINKpro or Arm DSTREAM debugger with Arm Development Studio or Keil uVision. Most issues can be debugged on the FVP too, which runs a debug server when the "-S" option is passed. Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 19 August 2019 13:45 To: Kevin Townsend <kevin.townsend(a)linaro.org> Cc: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Debugger setup for MPS2+ AN521 Hi, Any feedback at all on debugging TF-M on AN521 with a HW debugger, or confirmation someone has a working setup? I'm curious how people are digging into particularly complex problems, or things that happen very early on (pre-printf) if a standard HW debugger over SWD/JTAG isn't an option? Many thanks, Kevin On Tue, 6 Aug 2019 at 13:50, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > tl;dr: unable to connect to MPS2+ AN521 with JLink and perform a soft > reset to halt at NSPE init, and debug an init issue. Connect via SWD > fails, connect via JTAG seems OK, but soft reset requests consistently > fail, preventing meaningful debug/trace of the code. Looking for > advice on known-good debug setup with GDB and Linux. > > Full explanation follows: > > I'm currently working on an application with the following setup: > > - TF-M (latest) running in the secure processing environment > - Zephyr running in the NSPE > - PSA FF APIs to communicate between PEs > > I've run into a HW problem with the UART peripheral that I need to > debug, but using a J-Link has been problematic, and I was curious if > anyone else has had any success with GDB or JLinkExe and the MPS2+. > > To debug, I currently do the following: > > - Copy a valid TF-M + Zephyr and BL2 image to the MPS2+ > - Physically reset the MPS2+ (AN521) > - Wait for the image to start up (based on serial output) > - Connect the debugger > - Attempt to reset > > I get the following output at connect (entering the 'connect' command > at the J-Link prompt): > > NOTE: I've been unable to get SWD to work, and had to fall back to > JTAG for the interface. > > ---------------------------------------- > $ JLinkExe -device Cortex-M33 -if jtag -speed auto SEGGER J-Link > Commander V6.44i (Compiled May 17 2019 17:38:03) DLL version V6.44i, > compiled May 17 2019 17:37:52 > > Connecting to J-Link via USB...O.K. > Firmware: J-Link V9 compiled May 17 2019 09:50:41 Hardware version: > V9.10 > S/N: 609100327 > License(s): RDI, FlashBP, FlashDL, JFlash, GDB VTref=3.011V Device > position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect > JTAGConf>connect > ERROR while parsing value for IRPre. Using default: -1. > ERROR while parsing value for DRPre. Using default: -1. > Device "CORTEX-M33" selected. > > > Connecting to target via JTAG > TotalIRLen = 4, IRPrint = 0x01 > JTAG chain detection found 1 devices: > #0 Id: 0x6BA00477, IRLen: 04, CoreSight JTAG-DP Scanning AP map to > find all available APs > AP[3]: Stopped AP scan as end of AP map has been reached > AP[0]: APB-AP (IDR: 0x54770002) > AP[1]: AHB-AP (IDR: 0x84770001) > AP[2]: AHB-AP (IDR: 0x84770001) > Iterating through AP map to find AHB-AP to use > AP[0]: Skipped. Not an AHB-AP > AP[1]: Core found > AP[1]: AHB-AP ROM base: 0xF0008000 > CPUID register: 0x410FD211. Implementer code: 0x41 (ARM) Found > Cortex-M33 r0p1, Little endian. > FPUnit: 8 code (BP) slots and 0 literal slots Security extension: > implemented Secure debug: enabled CoreSight components: > ROMTbl[0] @ F0008000 > ROMTbl[0][0]: F0009000, CID: B105900D, PID: 000BB9A4 GPR > ROMTbl[0][1]: E00FF000, CID: B105100D, PID: 000BB4C9 ROM Table > ROMTbl[1] @ E00FF000 > ROMTbl[1][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 > ROMTbl[1][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT > ROMTbl[1][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB > ROMTbl[1][3]: E0000000, CID: B105900D, PID: 000BBD21 ITM > ROMTbl[1][5]: E0041000, CID: B105900D, PID: 001BBD21 ETM > ROMTbl[1][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI > Cortex-M33 identified. > ---------------------------------------- > > But any attempt to perform a soft reset fails, which makes debugging > the init code problematic: > > ---------------------------------------- > J-Link>r 0 > Reset delay: 0 ms > Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via AIRCR.SYSRESETREQ. > Reset: CPU may have not been reset (DHCSR.S_RESET_ST never gets set). > Reset: Using fallback: Reset pin. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > Reset: Core did not halt after reset, trying to disable WDT. > Reset: Halt core after reset via DEMCR.VC_CORERESET. > Reset: Reset device via reset pin > Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?). > Reset: Reconnecting and manually halting CPU. > AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 AP map detection skipped. Manually configured AP map found. > AP[0]: CUSTOM-AP (IDR: Not set) > AP[1]: AHB-AP (IDR: Not set) > AP[1]: Skipped. Invalid implementer code read from CPUIDVal[31:24] = > 0x00 > > ************************** > WARNING: CPU could not be halted > ************************** > > > ****** Error: Could not find core in Coresight setup > ---------------------------------------- > > If anyone is using a J-Link or J-Trace and ideally GDB to do any > meaningful debugging or tracing on the MPS2+ any suggestions on proper > setup would be valuable, and I'm happy to document an eventual working > config for inclusion in the project doc files. > > Barring that, an alternative GDB-based setup would be useful if > someone has a known-good solution? > > Best regards, > Kevin Townsend > -- > 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, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M