- TF-M - lists.trustedfirmware.org

by Anton Komlev

Hello, Let me announce the changes in TF-M project repository structure. To allow project grow up in a more organized way the existing codebase will be split on multiple repositories and placed under TF-M folder. This is the similar structure as all other projects have in git.trustedfirmware.org<https://git.trustedfirmware.org>. This weekend TF-M git repository will be moved from https://git.trustedfirmware.org/trusted-firmware-m.git to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git The original URL will be supported for some time (as a link to the new one) giving time for adjustment. Current plan is to keep the redirection for 6 months but let me know please, if it makes any conflict and another depreciation period is better. Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] Boot seed in TFM Attestation tests

by Tamas Ban

Hi Andrej, The value of boot_seed is compared against a hard coded value. This behaviour can be turned off in test/suites/attestation/attest_token_test_values.h. Then only the presence of boot_seed claim will be checked but its value not. Could you test this patch: diff --git a/test/suites/attestation/attest_token_test_values.h b/test/suites/attestation/attest_token_test_values.h index 5910524..fe2b9d4 100644 --- a/test/suites/attestation/attest_token_test_values.h +++ b/test/suites/attestation/attest_token_test_values.h @@ -110,6 +110,8 @@ /* A 32 byte mostly random value. Binary. * platform/ext/common/template/attest_hal.c */ +#define TOKEN_TEST_VALUE_BOOT_SEED NULL_Q_USEFUL_BUF_C +/* #define TOKEN_TEST_VALUE_BOOT_SEED \ (struct q_useful_buf_c) {\ (uint8_t[]){ \ @@ -120,6 +122,7 @@ },\ 32\ } +*/ #define TOKEN_TEST_REQUIRE_BOOT_SEED true /* Mandatory claim */ /* A text string in EAN 13 format Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 14 May 2020 12:06 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Boot seed in TFM Attestation tests Hello, Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail. The log: Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)... > Executing 'TFM_ATTEST_TEST_2004' Description: 'ECDSA signature test of attest token' decode_test_normal_sig() returned: -55 Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136) TEST FAILED! Is it know issue? Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()? Thank you, Andrej Butok

5 years, 5 months

1
0
0 0

Boot seed in TFM Attestation tests

by Andrej Butok

Hello, Using a real boot seed instead of the dummy one is causing a Attestation Service regression fail. The log: Running Test Suite Initial Attestation Service non-secure interface tests(TFM_ATTEST_TEST_2XXX)... > Executing 'TFM_ATTEST_TEST_2004' Description: 'ECDSA signature test of attest token' decode_test_normal_sig() returned: -55 Attest token decode_test_normal_sig() has failed (Failed at ../../../../../../middleware/tfm/test/suites/attestation/non_secure/attestation_ns_interface_testsuite.c:136) TEST FAILED! Is it know issue? Probably, it's better to use a real boot seed by the Attestation tests, returned by tfm_plat_get_initial_attest_key()? Thank you, Andrej Butok

5 years, 5 months

1
0
0 0

Re: [TF-M] Query on persistent keys Crypto API

by Soby Mathew

Hi Kevin > Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Yes, you are right, the Crypto service as implemented in TF-M positions it very close to 1.0 beta 3 API specification. There is still some unimplemented functionality and some differences in error code with respect to the Beta3 specification as reported by the compliance test suite here : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/t… > Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Yes, TF-M depends on mbedcrypto to provide the necessary functionality. This is work in progress and hopefully available towards Q3 timeframe. > If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Hopefully the solution suggested by Sherry is good enough for you to progress although your code will need to migrate to the API as specified in v1.0 at sometime in the future when TF-M implements the same. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 13 May 2020 12:25 To: Sherry Zhang <Sherry.Zhang2(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Query on persistent keys Crypto API Hi Sherry, Thanks for the quick response. The following sequence, explicitly closing the key after creation, seems to allow me to use psa_open_key, thank you: /* Import the private key, creating the persistent key on success */ psa_import_key(&key_attributes, key_data, key_len, &key_handle); /* Close the key to free up a volatile slot. */ psa_close_key(key_handle); /* Now try to re-open the persisted key based on the key ID. */ psa_open_key(key_id, &key_handle); Best regards, Kevin On Wed, 13 May 2020 at 12:48, Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> wrote: Hi Kevin, Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open). After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly. Hope it can help you! Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, May 13, 2020 5:47 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Query on persistent keys Crypto API Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

5 years, 5 months

1
0
0 0

Re: [TF-M] BL2 scatter file issue

by Tamas Ban

Hi Mark, Thank you, I think your observation is right. I have opened the following ticket to fix: https://developer.trustedfirmware.org/T749 Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 13 May 2020 17:13 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] BL2 scatter file issue Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

5 years, 5 months

1
0
0 0

BL2 scatter file issue

by Mark Horvath

Hi, I think there is an error in the usual BL2 scatter file, for example in platform<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform>/ext<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext>/target<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_b1<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Device<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/Source<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/armclang<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…>/musca_bl2.sct<http://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/tar…> The maximum size of the region ER_DATA is set to BL2_DATA_SIZE which is usually equals to the size of the available RAM. But not just the ER_DATA region have to be placed into RAM but also the BOOT_DATA, the heap and the MSP stack. In addition if the TFM_MULTI_CORE_TOPOLOGY macro is set then the BOOT_DATA is not placed at the start of the RAM in TF-M but after unprivileged data. So I would recommend to use the same check like in tfm_common_s.sct and adjust BOOT_DATA start: --- a/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct +++ b/platform/ext/target/musca_b1/Device/Source/armclang/musca_bl2.sct @@ -24,10 +24,10 @@ LR_CODE BL2_CODE_START { * (+RO) } - TFM_SHARED_DATA BL2_DATA_START ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { + TFM_SHARED_DATA BOOT_TFM_SHARED_DATA_BASE ALIGN 32 EMPTY BOOT_TFM_SHARED_DATA_SIZE { } - ER_DATA +0 BL2_DATA_SIZE { + ER_DATA +0 { * (+ZI +RW) } @@ -37,4 +37,15 @@ LR_CODE BL2_CODE_START { ARM_LIB_HEAP +0 ALIGN 8 EMPTY BL2_HEAP_SIZE { } + + /* This empty, zero long execution region is here to mark the limit address + * of the last execution region that is allocated in SRAM. + */ + SRAM_WATERMARK +0 EMPTY 0x0 { + } + + /* Make sure that the sections allocated in the SRAM does not exceed the + * size of the SRAM available. + */ + ScatterAssert(ImageLimit(SRAM_WATERMARK) <= BL2_DATA_START + BL2_DATA_SIZE) } What are your thoughts? Best regards, Mark

5 years, 5 months

1
0
0 0

Re: [TF-M] Query on persistent keys Crypto API

by Sherry Zhang

Hi Kevin, Yes, you are right. The persistent key management described in PSA Cryptograhphy version 1.0 is not supported yet. It still follows the version 1.0 beta3 “key management”. I also met the “INSUFFICIENT_MEMORY” issue when I am implementing the PSA based PKCS#11 shim layer. In my side, it is caused by multiple calling psa_open_key while the key is still open. Each persistent key is saved only once in non- volatile area. But each time you open a key with the key handle, a new volatile area is used. In your code, psa_open_key is called directly after psa_import_key. So in this case, an additional volatile area is taken. The default volatile area number is 16. I suggestion you check whether similar case happen in your code(calling psa_open_key while the key is in open). After provisioning, call psa_close_key to close the key. Then the volatile area is freed. Then to get the key handle later, you can call the psa_open_key directly. Hope it can help you! Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, May 13, 2020 5:47 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Query on persistent keys Crypto API Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

5 years, 5 months

2
1
0 0

Query on persistent keys Crypto API

by Kevin Townsend

Hi, Support for generating and working with persistent keys was recently merged into TF-M in the following change request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252/8 This corresponds to section 3.2.2 (Persistent keys) of the PSA Cryptography API 1.0 (dated 19/02/2020), although there seems to be some delay in implementing the functionality described in the API document. Page 209 ("Changes between 1.0 beta 3 and 1.0.0") states: "Removed psa_open_key and psa_close_key", but these functions are both present in the repo and seem to be used in the tests here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… Presumably this positions the merged change request around 1.0 beta 3, just to know where we stand with the API documentation versus implementation in TF-M? Since this is a very useful feature in real world applications, I was working on a sample application in Zephyr demonstrating how it might be used during device provisioning, and I was hoping to better understand the differences between the implementation in TF-M today and the 1.0 API document, specifically around KEY IDs versus key handle based access? The 1.0 API documentation, for example, describes: psa_status_t psa_export_public_key(psa_key_id_t key, uint8_t * data, size_t data_size, size_t * data_length); But TF-M implements this add: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… psa_status_t psa_export_public_key(psa_key_handle_t handle, uint8_t *data, size_t data_size, size_t *data_length); Presumably this migration to ID based accesses (versus handles) is still a work in progress, with a goal of perhaps being complete for 1.1? Should I still be calling psa_open_key in the interim, for example? Some examples like the AES + PKCS#7 test case here use that: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/cry… However, when I try to use psa_open_key when working with PSA_ECC_CURVE_SECP256R1, I get an INSUFFICIENT_MEMORY error, and I'm not sure how to get the psa_key_handle_t for subsequent operations like reading the key back. I've posted the WIP code that fails trying to open the key here: https://gist.github.com/microbuilder/a326cc6b935f87f413d89e44f9d3de05#file-… If I comment out the psa_open_key call, I CAN access the public key in the next function, but only because I have a reference to the handle from when we first persisted the key, but I wouldn't have that handle in the real world if I was accessing a previously created key, and it seems we can't access persisted keys via ID yet, only handles, unless I'm missing something (perhaps obvious)? Best regards, Kevin

5 years, 5 months

1
0
0 0

Profile Small design document is merged

by David Hu

Hi all, Profile Small design document is merged into TF-M design documents. Thanks again for your help and reviews. Comments and feedbacks are still and always welcome. The patch set to enable Profile Small is uploaded and under review. Could you please take a look at https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o… Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, May 7, 2020 12:03 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Request for final review of Profile Small design document Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - May 14

by Andrew Thoelke

Hi, Following on from the presentation and discussion on Ken's "Default Handles" proposal on 30 April, we have made some updates following the feedback and further implementation consideration. I (or Ken if he attends) can present an update on the proposal. I also mentioned last time that there is some missing context for this proposal. We are working on an update for PSA-FF-M v1.1 that will provide an enhancement of the v1.0 'IPC model' for secure services, and also a 'Secure Function model' which is similar to the 'library model' of TF-M today. The objective is a single architecture that enables secure service developers to select the framework features required for the complexity of the service; and the framework implementation to be optimised for simple systems. On Thursday, I would like to present an introduction to this PSA-FF-M v1.1 roadmap, and outline the steps that we think are required. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 06 May 2020 10:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 14 May 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 14 May 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, On 5/5/20 9:04 AM, Sandrine Bailleux via TF-A wrote: > I've received very little feedback on version 2 of the proposal, which > hints that we are reaching an agreement. Thus, I plan to finalize the > proposal this week. This can then become part of our development flow > for all trustedfirmware.org projects. > > Thanks again for all the inputs! The project maintenance process is now live. The document has been moved here (with a few minor edits to turn it from a proposal to an effective process): https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Thanks! Regards, Sandrine

5 years, 5 months

1
0
0 0

TFM 1.0 integration merged into upcoming Zephyr 2.3

by Kevin Townsend

Hi, Just as a FYI, TF-M 1.0 support was merged into Zephyr RTOS this week, meaning that it will be included by default in Zephyr starting with the upcoming 2.3 release. Zephyr is used on the non-secure side, and TF-M is used on the secure side, with the TF-M build happening as part of the normal Zephyr build process, meaning no knowledge of TF-M internals is required to get started. It's also worth highlighting QEMU integration with Zephyr+TF-M. Using the MPS2 AN521 target, you can run application from the command-line with QEMU, meaning that you can create test applications that use the PSA APIs with no HW required, or perform certain application tests purely in SW. As an example, the following sample was run with a clean install of Zephyr, showing QEMU output and demonstrating how to use the initial attestation, crypo and secure storage services: https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/tfm_integr… $ mkdir zephyrtfm && cd zephyrtfm $ west init $ west update $ west build -p -b mps2_an521_nonsecure zephyr/samples/tfm_integration/psa_level_1/ -t run [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! TF-M isolation level is: 1 Booting TFM v1.0 *** Booting Zephyr OS build zephyr-v2.2.0-2701-ge5aaf21a73c7 *** [00:00:00.003,000] <inf> app: app_cfg: Creating new config file with UID 0x155cfda7a [00:00:03.518,000] <inf> app: att: System IAT size is: 545 bytes. [00:00:03.518,000] <inf> app: att: Requesting IAT with 64 byte challenge. [00:00:06.925,000] <inf> app: att: IAT data received: 545 bytes. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 D2 84 43 A1 01 26 A0 59 01 D5 AA 3A 00 01 24 FF ..C..&.Y...:..$. 00000010 58 40 00 11 22 33 44 55 66 77 88 99 AA BB CC DD X@.."3DUfw...... 00000020 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000030 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000040 EE FF 00 11 22 33 44 55 66 77 88 99 AA BB CC DD ...."3DUfw...... 00000050 EE FF 3A 00 01 24 FB 58 20 A0 A1 A2 A3 A4 A5 A6 ..:..$.X ....... 00000060 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 ................ 00000070 B7 B8 B9 BA BB BC BD BE BF 3A 00 01 25 00 58 21 .........:..%.X! 00000080 01 FA 58 75 5F 65 86 27 CE 54 60 F2 9B 75 29 67 ..Xu_e.'.T`..u)g 00000090 13 24 8C AE 7A D9 E2 98 4B 90 28 0E FC BC B5 02 .$..z...K.(..... 000000A0 48 3A 00 01 24 FA 58 20 AA AA AA AA AA AA AA AA H:..$.X ........ 000000B0 BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC ................ 000000C0 DD DD DD DD DD DD DD DD 3A 00 01 24 F8 20 3A 00 ........:..$. :. 000000D0 01 24 F9 19 30 00 3A 00 01 24 FD 82 A5 01 63 53 .$..0.:..$....cS 000000E0 50 45 04 65 30 2E 30 2E 30 05 58 20 BF E6 D8 6F PE.e0.0.0.X ...o 000000F0 88 26 F4 FF 97 FB 96 C4 E6 FB C4 99 3E 46 19 FC .&..........>F.. 00000100 56 5D A2 6A DF 34 C3 29 48 9A DC 38 06 66 53 48 V].j.4.)H..8.fSH 00000110 41 32 35 36 02 58 20 B4 74 47 EE 2A 2C A4 73 B2 A256.X .tG.*,.s. 00000120 A5 55 D4 73 6D 7F 8B 42 97 94 C2 36 BC 03 33 04 .U.sm..B...6..3. 00000130 29 C3 E5 9C FF CD C4 A5 01 64 4E 53 50 45 04 65 )........dNSPE.e 00000140 30 2E 30 2E 30 05 58 20 B3 60 CA F5 C9 8C 6B 94 0.0.0.X .`....k. 00000150 2A 48 82 FA 9D 48 23 EF B1 66 A9 EF 6A 6E 4A A3 *H...H#..f..jnJ. 00000160 7C 19 19 ED 1F CC C0 49 06 66 53 48 41 32 35 36 |......I.fSHA256 00000170 02 58 20 07 16 EE 98 EA 6A CC 0F 7A 9A 21 46 E6 .X .....j..z.!F. 00000180 CD 26 B4 0B 3D 4B 35 B4 9C B1 89 57 56 12 66 AB .&..=K5....WV.f. 00000190 72 BD 47 3A 00 01 25 01 77 77 77 77 2E 74 72 75 r.G:..%.wwww.tru 000001A0 73 74 65 64 66 69 72 6D 77 61 72 65 2E 6F 72 67 stedfirmware.org 000001B0 3A 00 01 24 F7 71 50 53 41 5F 49 4F 54 5F 50 52 :..$.qPSA_IOT_PR 000001C0 4F 46 49 4C 45 5F 31 3A 00 01 24 FC 72 30 36 30 OFILE_1:..$.r060 000001D0 34 35 36 35 32 37 32 38 32 39 31 30 30 31 30 58 456527282910010X 000001E0 40 51 33 D9 87 96 A9 91 55 18 9E BF 14 7A E1 76 @Q3.....U....z.v 000001F0 F5 0F A6 3C 7B F2 3A 1B 59 24 5B 2E 67 A8 F8 AB ...<{.:.Y$[.g... 00000200 12 A3 AC 9C E8 44 95 13 60 82 E9 49 43 7B 4E C5 .....D..`..IC{N. 00000210 2C 0D E5 EC BA 72 C5 35 2C F7 C9 1C B7 26 93 80 ,....r.5,....&.. 00000220 12 . [00:00:06.982,000] <inf> app: Generating 256 bytes of random data. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 0C 90 D8 0C FA 0F 97 00 29 B2 AE 5C 90 48 3D 39 ........)..\.H=9 00000010 00 14 6C A3 84 E2 C0 C9 82 F5 8B A6 E9 38 66 16 ..l..........8f. 00000020 EA B7 E7 78 91 0D 6D 87 5B B8 04 0B 8B E0 74 23 ...x..m.[.....t# 00000030 7D 11 E2 17 32 34 1A 01 71 24 29 D5 7C 05 B1 11 }...24..q$).|... 00000040 A0 97 20 82 03 FF D6 76 9D 6F D5 52 45 C9 E1 17 .. ....v.o.RE... 00000050 69 DF 18 B6 8E 0C AA 3B 74 B4 EF 97 D9 0E 82 25 i......;t......% 00000060 E1 97 0E 6E 4F 0F DE B9 20 60 34 A4 EA 0D 9A B3 ...nO... `4..... 00000070 3F C4 9A CF F3 5E F2 2C 78 96 6F 0E DD E3 E6 CB ?....^.,x.o..... 00000080 DC 19 26 A3 E8 8E 07 0E 1E 5B DB 59 B0 05 41 E2 ..&......[.Y..A. 00000090 A4 ED 90 35 8B AB 1C B8 00 7E BB 2D 22 FE 7A EA ...5.....~.-".z. 000000A0 CF A0 BB DF 4F 2B 32 55 C9 07 0D 3D CE B8 43 78 ....O+2U...=..Cx 000000B0 63 33 6C 79 CA 43 3A 4F 0B 93 33 2B B1 D2 B0 A7 c3ly.C:O..3+.... 000000C0 44 A0 E9 E8 BF FB FD 89 2A 44 7A 60 2D 9B 0F 9E D.......*Dz`-... 000000D0 0D B1 0E 9D 5C 60 5D E6 92 78 36 79 68 37 24 C5 ....\`]..x6yh7$. 000000E0 57 7F 2E DF 53 D2 7B 3F EE 56 9B 9E BB 39 2C B6 W...S.{?.V...9,. 000000F0 AA FF B5 3B 59 4E 40 1D E0 34 50 05 D0 E0 95 12 ...;YN@..4P..... [00:00:07.004,000] <inf> app: Calculating SHA-256 hash of value. 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000000 E3 B0 C4 42 98 FC 1C 14 9A FB F4 C8 99 6F B9 24 00000010 27 AE 41 E4 64 9B 93 4C A4 95 99 1B 78 52 B8 55 A big thanks to Karl, who was involved in getting this integration work going during his time as an assignee to the LITE team at Linaro, and to other members of the Zephyr community who got this over the finish line at the last minute, as well as to Mate for some last second feedback and debugging with TF-M in IPC mode using Zephyr. We hope this will make TF-M, and all the hard work that has gone into it, far more accessible to a wider range of people, with HW no longer being an immediate limitation to trying it out. Best regards, Kevin Townsend, Linaro

5 years, 5 months

1
0
0 0

Remove 'INDIVIDUAL_SW_COMPONENTS' support from attestation

by Tamas Ban

Hi, I let you notify that 'INDIVIDUAL_SW_COMPONENTS' support is planned to be removed from attestation service and bootloader. What is this? * Boootloader and SPE can exchange data through shared memory. This is needed to provide the boot status info to attestation service. The boot status info is included in the SW_COMPONENT claim in the attestation token. * Until now two types of data encoding was supported during this data sharing: * All boot status data item is passed as a single TLV entry: -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS * Boot status is already encoded to CBOR format at build time. Bootloader only updates a few field in it, and pass the CBOR object to SPE. Then attestation service just include this already CBOR formatted object to the token, without the need to applying further encoding. -DATTEST_BOOT_INTERFACE=CBOR_ENCODED_CLAIMS The 'INDIVIDUAL_CLAIMS' format is marked as deprecated feature for a while in the code base. Now the plan is to remove it and rely fully on the 'CBOR_ENCODED_CLAIMS' format. The build system support for this is present in TF-M for a long, and recently it was upstream to original MCUBoot 'imgtool' script as well. Next MCUBoot release (v1.6) will contain it. If you has any objection, because your project is using the 'INDIVIDUAL_CLAIMS' format then please let us know! BR, Tamas

5 years, 6 months

1
0
0 0

Request for final review of Profile Small design document

by David Hu

Hi all, Profile Small design document has been reviewed for a long time. Thanks a lot for all your comments and suggestions. I'd like to request a final round review. If no further critical comment, the Profile Small design document will be merged next Wednesday. If you have interest in reading the document again, please access https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - May 14

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 14 at 15:00-16:00 UTC. Please reply on this email with your proposals for agenda topics. To avoid confusion here are some local times: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=… Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 14 May 2020, 08:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 14 May 2020, 10:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 14 May 2020, 16:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 14 May 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Invitation: TF-M tech Forum (Asia TZ) @ Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 May to Sat 1 Aug (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M tech Forum (Asia TZ) About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 4 weeks from 07:00 to 08:00 on Thursday from Thu 28 May to Sat 1 Aug United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MjJva2xwOGVxaG12bHVha… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 6 months

1
0
0 0

Invitation: TF-M Tech Forum (US TZ) @ Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum (US TZ) About TF-M Tech forum:This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 4 weeks from 16:00 to 17:00 on Thursday from Thu 14 May to Sat 1 Aug United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MW5vZW9lcmloY2l2aWhpa… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 6 months

1
0
0 0

Re: [TF-M] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, I've received very little feedback on version 2 of the proposal, which hints that we are reaching an agreement. Thus, I plan to finalize the proposal this week. This can then become part of our development flow for all trustedfirmware.org projects. Thanks again for all the inputs! Regards, Sandrine Bailleux

5 years, 6 months

1
0
0 0

IAR related changes needing review and merge

by Thomas Törnblom

I have submitted a few patches to allow building with IAR after recent changes. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3982 https://review.trustedfirmware.org/c/trusted-firmware-m/+/3997 https://review.trustedfirmware.org/c/trusted-firmware-m/+/4022 I would be happy for review and merge. Thanks, 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, 6 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Thomas Törnblom

Hi Kevin, Are there any plans to add ARMCLANG as a build environment for this? If so, then I can add an IAR port as well. Going from ARMCLANG to IAR is much easier than to go from GNUARM to IAR. I have access to one of these boards so will be able to run regression tests as well. Cheers, Thomas Den 2020-04-29 kl. 15:03, skrev Kevin Townsend via TF-M: > Hi, > > Just a quick note that support for the LPC55S69 was just merged in, > allowing you to use the relatively easy to source LPCXpresso55S69-EVK > dev board: > https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… > > Some notes on how to use this board with TF-M are visible here, > including how to update the board to use the Segger J-Link firmware > image: > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > Samples scripts for building and flashing (which assume the J-Link > debug firmware is present) are available here: > > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > - > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… > > If you find any issues with the board support, you can comment on the > LPC55S69 task here: https://developer.trustedfirmware.org/T706 > > Best regards, > Kevin Townsend > -- *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, 6 months

2
1
0 0

Improve library model secure function entry points

by David Hu

Hi all, I uploaded a patch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/4009) to simplify/improve the entry points of secure functions in Library model. In current Library model implementation, each secure function includes the same inline entry point tfm_core_partition_request(). Actually, only the NS client check is required to be inline. The duplicated entry points cost much code size. Thus this patch extracts NS client check and make it as a simple inline function tfm_core_is_ns_client(). tfm_core_partition_request() becomes a normal function called by each secure function. Some quantitative results of code size optimization (about 3KB) are shown below: Profile Small (ConfigDefaultProfileS) is based on https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o… ConfigDefault + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 129778 8994 272 50108 Improved 126294 8994 272 50108 ConfigDefaultProfileS + Armclang 6.10 + Release + AN521 Code RO-data RW-data ZI-data Current impl 55886 3274 200 31664 Improved 52930 3274 200 31664 Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

Re: [TF-M] PSA Crypto failure with addition of persistent keys

by Vinay Kumar Kotegowder

Hi Raymond, There are some changes required for PSoC64 target with the recent changes from Jamie on persistent key support for test_c050 (api-tests/dev_apis/crypto/test_c050). I will be pushing changes to GitHub today. You could try them and let us know if you are still facing problem. Regards, Vinay ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 27, 2020 8:03 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Jamie Fox <Jamie.Fox(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Crypto failure with addition of persistent keys Hi Raymond, Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250. Could you please share more details and error logs of this test case? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: Monday, April 27, 2020 10:26 AM To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com> Subject: [TF-M] PSA Crypto failure with addition of persistent keys Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. Thank you, Ray 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. 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. 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.

5 years, 6 months

2
2
0 0

Re: [TF-M] TF-M Technical Forum call - April 30

by Anton Komlev

Hello, The agenda of the call is: 1. introduction to a mechanism efficiency improvement by reducing 'psa_connect'/'psa_close'calls. 2. Mailing List topics discussion (optional) 3. AOB Best regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 28 April 2020 07:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - April 30 Hi Anton, I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - April 30 Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] LPC55S69 support merged into master

by Andrej Butok

Hi Kevin, Thank you very much for your successfully efforts and taking care for the TFM LPC55S69 upstream. Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Wednesday, April 29, 2020 3:04 PM To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] LPC55S69 support merged into master Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.c…> Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Best regards, Kevin Townsend

5 years, 6 months

1
0
0 0

LPC55S69 support merged into master

by Kevin Townsend

Hi, Just a quick note that support for the LPC55S69 was just merged in, allowing you to use the relatively easy to source LPCXpresso55S69-EVK dev board: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Some notes on how to use this board with TF-M are visible here, including how to update the board to use the Segger J-Link firmware image: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… Samples scripts for building and flashing (which assume the J-Link debug firmware is present) are available here: - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… - https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta… If you find any issues with the board support, you can comment on the LPC55S69 task here: https://developer.trustedfirmware.org/T706 Best regards, Kevin Townsend

5 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M