- TF-M - lists.trustedfirmware.org

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

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, About the CMSIS documentation change, could you share us the difference to be updated? Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 10:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Ken, Thanks for feedback. TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread. When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version. Long story short: * I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution. In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works. Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, OK, the problem is caused by that the names of region related symbols that IRA compiler generate are different with those of ARMCLANG. The work around below do can solve the problem. BTW the work around seems not to be a general one. I think another way to solve the problem is adding a macro like SYMBOL_NAME_BASE(region) which is a wrapper of the REGION_NAME on different compilers. Regards, Sherry Zhang From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: Tuesday, April 28, 2020 6:28 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] REGION_DECLARE macros Hi Sherry, Yes, I noticed that this change had been integrated and that this symbol was being used. I ran into a lot of these during the IAR port and as I said they don't work with the IAR linker. I work around this in CommonConfig.cmake by this define: --- embedded_set_target_compile_flags(TARGET ${tgt} LANGUAGE C FLAGS ${COMMON_COMPILE_FLAGS} "-DImage$$= " "-DLoad$$LR$$= " "-D$$ZI$$Base=$$Base" "-D$$ZI$$Limit=$$Limit" "-D$$RO$$Base=$$Base" "-D$$RO$$Limit=$$Limit" "-D$$RW$$Base=$$Base" "-D$$RW$$Limit=$$Limit" "-D_DATA$$RW$$Base=_DATA$$Base" "-D_DATA$$RW$$Limit=_DATA$$Limit" "-D_DATA$$ZI$$Base=_DATA$$Base" "-D_DATA$$ZI$$Limit=_DATA$$Limit" "-D_STACK$$ZI$$Base=_STACK$$Base" "-D_STACK$$ZI$$Limit=_STACK$$Limit" --- i.e. I replace $$ZI$$Base with $$Base, Image$$ and Load$$LR are removed entirely, and so on. To make this work I need to split the symbol up into its components, which is done with the REGION macros. So the symbol "Image$$ARM_LIB_STACK_MSP$$ZI$$Base" turns into "ARM_LIB_STACK_MSP$$Base", which is what we use for IAR. For ARMCLANG and GNUARM the macros generate the original symbol. Cheers, Thomas Den 2020-04-28 kl. 12:03, skrev Sherry Zhang: Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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> -- 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> -- 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

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

Hi Ken, Thanks for feedback. TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_… The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread. When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version. Long story short: * I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution. In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works. Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by David Wang

Hi Reinhard, Add more from user's perspective: The non-secure client id can be used to identify different "clients" from non-secure side. The example from tf-m existing secure service is the storage. Different client id can access different storage space. Therefore, the storage is "isolation" among the clients. The users can create the custom secure service and leverage different client ids (let's say non-secure client id here) to identify different non-secure "callers": * The meaning of identifying different non-secure callers depends on the user case of the secure service. For example, different storage spaces, different access permissions, etc. * In RTOS, different non-secure client ids are managed via TZ_APIs (https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu…) if they're enabled. * The mapping between non-secure applications and the TZ secure contexts (stand for different client ids in tfm) is managed by NS RTOS kernel. When the ns applications get updated, then the mapping should also be maintained by RTOS kernel. Hope this helps. Refs: [1]: TF-M non-secure ID manager http://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides… [2]: PR to FreeRTOS which uses different non-secure id for storage service: https://github.com/Linaro/amazon-freertos/pull/1 Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, April 28, 2020 7:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 2:57 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] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

Hi Reinhard, My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management. Still need the real USER to provide more information in case my assumption covers partial scenarios only. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

Hi Thomas, The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 . REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler? Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, April 28, 2020 4:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] REGION_DECLARE macros I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Tï¿½rnblom via TF-M: With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ $$ZI$$Base)); --- 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> -- 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] REGION_DECLARE macros

by Thomas Törnblom

I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software. Trying another type: /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); Den 2020-04-28 kl. 10:51, skrev Thomas Törnblom via TF-M: > With the integration of the IAR toolchain support in TF-M it has > become important to use the REGION_DECLARE/REGION_NAME macros in > platform/region.h instead of using symbols like > "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". > > The IAR linker can not use these symbols and the macros in combination > with the IAR specific cmake rules creates appropriate symbols for all > the supported toolchains. > > Example diff: > --- > ï¿½ï¿½ï¿½ï¿½ /* Set Main Stack Pointer limit */ > -ï¿½ï¿½ï¿½ extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; > -ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); > +ï¿½ï¿½ï¿½ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,ï¿½ $$ZI$$Base); > +ï¿½ï¿½ï¿½ __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, > +ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ > $$ZI$$Base)); > --- > > 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> > -- *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

REGION_DECLARE macros

by Thomas Törnblom

With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base". The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains. Example diff: --- /* Set Main Stack Pointer limit */ - extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base; - __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base); + REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base); + __set_MSPLIM((uint32_t)&REGION_NAME(Image$$, ARM_LIB_STACK_MSP, + $$ZI$$Base)); --- 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

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled. However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime. Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] Documentation for platform interfaces

by Minos Galanakis

Hi Reinhard I think the closer to a high level documentation is this page: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… To your question regarding the nv counters, they are currently used by MCUBOOT and Protected Storage Service. You may be interested in this patch under review which is will expose them as a service https://review.trustedfirmware.org/c/trusted-firmware-m/+/3367 Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 April 2020 16:07 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Documentation for platform interfaces Is there somewhere a high-level documentation for the platform interfaces that are here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ… What are the dependencies of the services to the platform files? For example, when is nv_counters used? Reinhard

5 years, 6 months

2
1
0 0

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

by Ken Liu

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> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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

Documentation for platform interfaces

by Reinhard Keil

Is there somewhere a high-level documentation for the platform interfaces that are here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ… What are the dependencies of the services to the platform files? For example, when is nv_counters used? Reinhard

5 years, 6 months

1
0
0 0

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

by David Hu

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.

5 years, 6 months

1
0
0 0

PSA Crypto failure with addition of persistent keys

by Raymond Ngun

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.

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model

by Ken Liu

Looks no more feedbacks. We will start creating it and call for review when finished. Issue created for collecting comments: https://developer.trustedfirmware.org/T720 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, April 9, 2020 4:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 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] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 6 months

1
0
0 0

Request for comments on TF-M Profile Small design updates

by David Hu

Hi all, Hope you are doing well. May I ask for your review on the latest Profile Small design? The design has been updated with following major changes: * The default AES mode is changed to CCM mode from CBC mode, to achieve more secured connection. * More details on the use case of Profile Small Please review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Please feel free to comment. Thank you! The patch set is updated as well, following the latest design. Please check it on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Compared with previous versions, CCM is supported and some configurations are selected to optimize the Crypto memory footprint. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - April 30

by Anton Komlev

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] Build issues with MCUBoot merge

by Tamas Ban

Bug fix merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3943 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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 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 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

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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 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 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

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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 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

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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

1
0
0 0

Build issues with MCUBoot merge

by Thomas Törnblom

I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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] Will TFM crypto service suppot national encryption algorithm in the future?

by Shebu Varghese Kuriakose

Hi Matt, TF-M plans to continue using Mbedcrypto in the crypto service. Mbed Crypto implements the PSA Crypto APIs and is also now part of trustedfirmware.org community project alongside TF-M. However, it is possible with some effort for a platform using TF-M to use another crypto library in the TF-M crypto service. Of course the library will need to support PSA Crypto APIs to be PSA compliant. There is support for ARIA, Camellia in Mbed TLS. There has already been a PR for SM4 support sometime back - https://github.com/ARMmbed/mbedtls/pull/1165. SM2/SM3 algorithm support can be contributed to MbedTLS project (Mbed Crypto is now merged to Mbed TLS project). The maintainers will have to review and integrate the contribution as their bandwidth permits while finding time to review several contributions that the project is receiving. I am adding psa-crypto mailing list which is used for Mbedcrypto/PSA Crypto discussions. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M Sent: Thursday, April 16, 2020 8:24 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future? Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 6 months

2
1
0 0

Will TFM crypto service suppot national encryption algorithm in the future?

by Matt

Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 6 months

1
0
0 0

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

by Sandrine Bailleux

Hi all, Thanks to all who have commented on this proposal so far. I've edited the original document to try and incorporate all feedback gathered so far (through the TSC meeting, this email thread and the TF-A tech call). Please have another look and flag anything I might have missed: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… The major changes are: == Removed concept of self-review == This is proving too controversial, several people do not want to allow self-review. Roles of maintainer and code owner are still cumulative but cannot be both exercised for the same patch. The exact method of dealing with review bottleneck is still to be decided. In addition to the current proposal of increasing the maintainers pool, the most popular alternatives mentioned so far are: - Set a minimum wait time for feedback before a patch can be merged without any further delay. - Mandate distinct reviewers for a patch. == Enhanced the section "Patch contribution Guidelines" == Mentioned that patches should be small, on-topic, with comprehensive commit messages. == Added a note about how to deal with disagreement == If reviewers cannot find a common ground, the proposal is to call out a 3rd-party maintainer. == Removed "out-of-date" platform state == Squashed it into "limited support" to reduce the number of states. == Removed "orphan" state from platform support life cycle == This concept is orthogonal to the level of functionality. Added a note in the "Code Owner" section instead. == Per-project guidelines as a complementary document == Added a list of things that it would typically cover. == Added requirement on fully supported platforms to document the features they support == == Added todo mentioning that the proposal might cover branching strategies in the future == The full diff may be seen here: https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5 This proposal is still open for discussion at this stage and further feedback is most welcome! Regards, Sandrine

5 years, 6 months

1
0
0 0

Design of symmetric key algorithms based Initial Attestation in TF-M

by David Hu

Hi all, Hope you all well! Profile Small (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598) includes symmetric key algorithm based Initial Attestation, as its Initial Attestation feature. I propose a design of symmetric key algorithm based Initial Attestation in TF-M, to complete the Profile Small feature list. Could you please take a look the design document at https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898/? Any feedback is welcome! I also upload a PoC of symmetric key algorithm based Initial Attestation in TF-M. Please check the patch set at https://review.trustedfirmware.org/q/topic:%22symmetric-attest%22+(status:o…. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - April 16

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, April 16 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

Invitation: TF-M Tech Forum @ Every 2 weeks from 07:00 to 08:00 on Thursday 2 times (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum 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 2 weeks from 07:00 to 08:00 on Thursday 2 times 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=NmJrNmtzbHVyYThiczFkY… 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] Multi-threaded single-scheduler model proposal

by Shreve, Erik

I see the discussion of today's tech forum agenda has begun ahead of time. :) Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW. No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code. The qualifier in this statement "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. I believe we need a middle ground to drive additional adoption. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Thursday, April 02, 2020 9:47 AM To: Reinhard Keil; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal I used crypto accelerator as a hypothetical example. In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms). It is not acceptable to be parked in wfe during that time. Alan From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:52 AM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

5 years, 6 months

3
4
0 0

Re: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Jamie Fox

Hi Andrej, Key derivation should be deterministic - given the same input parameters, tfm_plat_get_huk_derived_key() should always derive the same key. Each platform needs to implement tfm_plat_get_huk_derived_key() to use a key derivation function (KDF) to derive keys from the hardware unique key (HUK) that is kept in some one time programmable (OTP) memory on the chip. Depending on the platform, the key derivation might be done with a crypto accelerator, or it might be done with a software implementation of a KDF if no accelerator is available. You can use the Musca-B1 implementation as an example (https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…), which uses CryptoCell-312 to derive keys from the HUK. Other Arm platforms only have dummy implementations of this function. In general, users of this API will keep their derived keys in volatile memory and redo the key derivation on each boot, as the cost of key derivation is low. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 09 April 2020 11:49 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage? Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

5 years, 6 months

2
1
0 0

Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Andrej Butok

Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu)

by Ken Liu

Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 6 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Ken Liu

Hi Erik, Could you share us more design details such as the slides you presented in Tech Forum, the progress and so on? We want to see more details (the more the better I think) and then we could discuss more precisely. Also, if this design has been prototyped, try to collect some data would be much helpful. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:51 PM To: Shreve, Erik <e-shreve(a)ti.com>; DeMars, Alan <ademars(a)ti.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Erik, I believe we should measure timing behaviour and document it first before come to conclusions. Personally I have not reviewed the IPC mode. I was just reviewing the SFN (aka Library mode) and measured the current implementation (actually it was a RC3+patches version). My result and assessment is here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html - it has as expected for v1 "room for improvement". Did you do similar tests with the IPC model already? Do you have timing measurements of the HW crypto accelerator operations? From the STM32L5 data sheet we are getting 410 cycles as the maximum time of an AES 256-byte key decrypt operation (most operations seems to take less than 100 cycles). The fact that crypto is time consuming is not new for system designers that use a single core processor. As said the solution in today's applications is: * Crypto is in "Normal" priority * Time critical execution is "High" priority - this threads can preempt execution of "Normal" priority threads. Have a happy Easter time and stay healty! Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Tuesday, April 7, 2020 3:24 PM To: Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.com>>; DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal Reinhard, I'm happy to engage in discussion over email. Didn't mean to send any other impression. Also, appreciate your feedback on the proposal. Elegance is in the eye of the beholder, but that said I think that the IPC model does have an elegance to it. However, its elegance imposes limitations that complicate the entirety of _some_ systems - leading to less overall elegance in _those_ systems. The IPC model isn't bad or inappropriate, it's a great solution. It just doesn't cover everything (what could?) Further, if a middle ground is needed but there exists no 'elegant' solution then a solution a bit less than elegant may be required. Also, no debate that the IPC model is not much different from when users are running mbedTLS only in a dedicated thread, but that is not how we see crypto used in our ecosystem. There are many industrial and automotive use cases where determinism is required. Further, both of these markets are seeing an uptick in security interest and even regulation pressure. And these markets don't like change. Change implies opening products back up to costly verification and validation activities and risk. I can't share particulars on this email list, but I can say that any system supporting multiple concurrent connections wherein different connections have different priority and at least some of those have deterministic response requirements will have difficulty adopting the IPC model. (Of course there are other ways to solve this such as increased clock rate or duplicated HW accelerators, but these impact die cost and can negatively impact power performance.) Keep in mind that not all connections are TLS connections over the internet where a few milliseconds would be noise. But based on your statement "Maybe there are other solutions that extending the RTOS kernel," I'm wondering if I've not communicated the idea well enough. The RTOS kernels would only be extended by the calling of tz_context APIs during task switching. This is something that is already occurring in the IPC model. (You mention that using the tz_context APIs is "tricky," can you elaborate more on this?) There is then a TF-M _to_ RTOS layer allowing secured code to signal semaphore and mutex usage to the RTOS. The RTOS kernel itself has no changes for this layer. Thus, I see the impact to the RTOS kernels as minimal. And since the RTOS retains the same control over when tasks run, there is minimal (if any) impact to application code. I think one of your concerns is adoption of TF-M and that it may be negatively impacted if difficult integration with each RTOS is required. Yes? If so, I am sharing your concern about adoption, but I think the bigger hindrance is not the RTOS integration but application level integration. After all there are far fewer RTOSes than applications in the world. Likely our different experiences are leading us to different conclusions here despite a shared concern. But providing a few well selected options can maximize adoption for effort. At the end of the Tech Forum meeting someone suggested a model like this could replace (or upgrade) the Library model. Regarding HW run times, the specifics really are in cycle counts if we want to compare them with the cost of task switching. Many ECC (and certainly RSA/DSA/DH) math operations take much longer (millions of cycles) than the time to switch a task. Finally, regarding minimal viable product (MVP), I understand the purpose of an MVP to either be a platform to gain feedback toward a product launch or a minimum product that is useful to early adopters. Either way, it seems that with the release of TF-M 1.0 this has been achieved. So then the next steps are to incorporate feedback and grow the market of the product. Growing the market use of TF-M is what I seek to do with the proposal. Again, appreciate the discussion. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Friday, April 03, 2020 7:26 AM To: Shreve, Erik; DeMars, Alan Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Erik, Alan, Sorry I had not enough time to participate the whole meeting yesterday and I therefore kicked-off some discussion before. It's really great to see your engagement here. Let me summarize: TF-M should work with many different RTOSes as the various CSPs currently have preferences (Azure=ThreadX, AWS=FreeRTOS, etc.). To make it easy to work with this diverse eco-system we should aim for simplicity of TF-M/RTOS interaction. Also tz_context slows down overall thread switching and is tricky to use. I agree with you that we will need a middle ground. You say: "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. However I cannot see today an elegant solution. My question is: what use-cases do you see where two different threads need to call secure services. Is in such use-cases timing a critical factor? Alan raised "In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms)". This is correct, but makes it really sense to schedule CPU execution. HW accelerator math operations take some ~1usec; thread scheduling is not economic. IMHO: It is not different from today's implementation where i.e. mbedTLS is running in a thread. For time critical applications you would solve that problem with thread priorities where: * Crypto is in "Normal" priority * Time critical execution is "High" priority I believe we should focus first on a minimum viable product and then analyze the real-world problems that come with it. Maybe there are other solutions that extending the RTOS kernel. Have a good weekend. Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Thursday, April 2, 2020 4:55 PM To: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>>; Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal I see the discussion of today's tech forum agenda has begun ahead of time. :) Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW. No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code. The qualifier in this statement "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. I believe we need a middle ground to drive additional adoption. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Thursday, April 02, 2020 9:47 AM To: Reinhard Keil; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal I used crypto accelerator as a hypothetical example. In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms). It is not acceptable to be parked in wfe during that time. Alan From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:52 AM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

5 years, 6 months

1
0
0 0

[RFC] The veneer usage under library model (Ken Liu)

by Reinhard Keil

Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 6 months

1
0
0 0

[RFC] The veneer usage under library model

by Ken Liu

Hi, There are veneer prototypes in 'tfm_veneers.h', with different function name but the same parameters. These veneers are for the library model. I think these veneers can be combined into one and use a parameter 'type' to dispatch to the actual functions. What do you think about this update? Would this change impact your development much? Please provide your comments. Thanks. /Ken

5 years, 6 months

1
0
0 0

Re: [TF-M] [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

I realise non TF-A people may not have access to session conference details. These can be found here: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000330.html From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Tuesday, 7 April 2020 at 18:10 To: tf-a <tf-a(a)lists.trustedfirmware.org> Cc: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, "op-tee(a)linaro.org" <op-tee(a)linaro.org> Subject: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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

1
0
0 0

TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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

1
0
0 0

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

by Sandrine Bailleux

Hi Joakim, On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote: > Hi Sandrine, > > On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote: >> Hi Joakim, >> >> On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: >>> How that works in practice is that all OP-TEE maintainers are adding >>> their "Tested-by" (see example [2]) tag for the platform they maintain >>> when we're doing a release. If there are platforms with no "Tested-by" >>> tag, then they simply end up with the "last known version". >> >> I think that's a very good idea! >> > The "Tested-by" part for OP-TEE releases has been working pretty good, > not sure how scalable it is the long run though. To give some more > info regarding the "last known version", we even at one point had some > stop-light for that. I.e. if a maintainer missed testing a release once, > then it became "orange". If missed twice, then it became "red" and we > showed last know supported version. But we dropped that idea a short > while after introducing it. May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info). >>> However, to keep that up-to-date, it requires some discipline from the >>> people maintaining such a table ... something that we in the OP-TEE >>> project haven't been very good at :) >> >> Can't this be automated, such that it doesn't need to be manually kept >> up-to-date? I imagine we could have some tools generating the platform >> support table out of such a commit message. >> > Indeed it could, it's just a matter of doing some scripting if one > doesn't want to do it manually. I already have Python scripts pulling > all tags from GitHub pull requests. But there are of course several > other ways how one could pull that kind of information. Regards, Sandrine

5 years, 6 months

2
1
0 0

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

by Sandrine Bailleux

Hi Erik, On 4/1/20 9:24 PM, Shreve, Erik via TF-A wrote: > Sandrine, > > To clarify on functionality vs. support. I listed out a support life cycle consisting of the following states: > Fully Supported > Orphan > Out of Date > Deprecated > These states are intended to have nothing to do with functionality, but only the support offered for the functionality that currently exists for a platform. > > I think I may have confused things when I listed "Functional Support" as the heading to represent "Functionality." > I'm proposing that the supported "Functionality" should be documented in a standard way (within a project) for every platform. > > I do agree this could be burdensome to keep up with. But that is why I suggested that the project's feature list be versioned. The platform's supported feature list document would reference the version of the project feature list used. Platform maintainers then don' t have to continuously update the document. But it will be clear how long it has been since they did update and thus what information may be missing. Versioning the feature list document is also why I mentioned that the project version number may want to adopt a version number scheme where feature changes are represented by a certain part of the version number. For example Semantic Versioning 2.0.0: https://semver.org/. Hope that clarifies the intent? For implementation of this I'm imagining each project could create a supported_feature_list.rst file and each platform would copy that file into their platform doc folder and fill it in. I'm not saying that approach would be required at tf.org level, just sharing to further illustrate. > > That said, perhaps the implementation details for a project would not warrant such a document per platform? My primary concern around this is misuse/misconfiguration. If a platform doesn't support a feature or configuration it may not be obvious to a user unless an error is generated at build or run-time. OK, I think I get the idea now, thanks for the explanations. This looks reasonable to me. The idea of keeping a project's feature list being mirrored and filled in per platform sounds like something we would want to enforce at the tf.org level IMO. At the same time, this could also be handled at the build system level as you pointed out, or more precisely by the configuration manager. I am thinking about the Linux kernel, where support for a particular feature is handled (and documented) through the KConfig system. This might be a more scalable approach. And it doesn't prevent us from also auto-generating some feature list out of the Kconfig files for making this information more accessible to users. > My secondary concern is being able to consistently track tickets/bugs with features. Thus, I'm recommending that the features on that list be used with the ticket/issue system by feature name. This would allow users to find all bugs for Feature X on Platform Y in Project Z. > Related to that, when I mentioned "tags." I wasn't thinking of Git tags, but "labels" in the ticket/issue tracking system(s). Different systems work differently for labeling/categorizing issues, but the goal is to provide a consistent way (per project) to find issues related to a feature on a platform. > > If requiring a feature list it is too much at the tf.org level then I'll be satisfied to push for that kind of documentation in the projects or platforms I'm involved in if/as appropriate. Yes, good point, I think it would be desirable to be able to tie tickets to some specific platform/feature/version. And I think it makes sense to unify this across tf.org projects. > Regarding the other conversational tidbits: > > Thanks for pointing out that the original proposal does say "builds all configurations supported by this platform" under "Fully Supported." I can see the intention here now. Substituting "features" for "configurations" would broaden the meaning a bit. OK, I will change the wording, thanks for the suggestion. > You said: "I am starting to think that we need a list of items to be defined per project." > Yes, this sounds like a great idea. > > My original mention of wanting a "stronger standard put forth for platform documentation" was a response to seeing "Limited Support" in the original proposal allowing documentation to fall out of date. > > > Hope that clarifies some of my thoughts. If not, I'm happy to continue the discussion. Thanks again for taking feedback! > > Erik Shreve, PSEM > Software Security Engineer & Architect (CMCU Platform Development) > > -----Original Message----- > From: Sandrine Bailleux [mailto:sandrine.bailleux@arm.com] > Sent: Wednesday, April 01, 2020 4:18 AM > To: Shreve, Erik; tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org > Cc: nd(a)arm.com > Subject: Re: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects > > Hello Erik, > > Thanks for the feedback. > > On 3/26/20 3:37 PM, Shreve, Erik wrote: >> Sandrine, >> >> Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. >> >> As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. >> I'd like to see these split out. > > Yes, you are the second person to mention that and I agree with you > both. Unless someone disagrees, I intend to update the proposal and > separate these 2 concepts in the next version of the document. > >> For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. >> A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. > > I completely agree. It would not make sense to support all features on > all platforms just for the sake of completeness. Each platform ought to > implement what is relevant in its case. > > That's what the current proposal tried to convey: a fully supported > platform must "build all configurations *supported by this platform*" > and "All *supported* configurations are tested in the CI". The key word > here is supported and that would be defined by the platform itself. But > I can see that maybe this wasn't clear enough. Your proposal below makes > that a lot clearer. > >> Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. > > Fair point. > > But is it something we should include in this proposal or should we push > it to a separate document setting expectations for the project's > documentation, which the current general proposal could refer to (as in, > "the platform should provide quality documentation up to the project's > criteria defined in document XXX')? > > This is definitely an important topic but I am wary of keeping the > tf.org proposal concise and focused at this point. I am worried that if > we put too much stuff in it discussions will diverge too much and we > might never reach an agreement. > > The same applies to testing standards for example, we could detail that > in the proposal or simply leave it to projects to define it separately. > >> Here is a more concrete proposal: >> >> Functional Support: >> Each project shall provide a standard feature or functionality list. >> Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. >> The platform documentation may reference a ticket if support is planned but not yet present. >> The platform documentation shall explicitly state if a feature or function has no plans for support. > > Regarding the last item, this would require all platform maintainers to > update their documentation every time a new feature is added to the > project's global list of features. This seems too much of a constraint > and unnecessary maintenance burden to me. > > I think a better, more lightweight alternative might be to let platform > maintainers list what's supported and if some feature is not listed, it > implies that it is not supported. This does not prevent platform > maintainers from indicating their future plans of supporting a feature > if they want to. > >> The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. >> In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. > > I can see that Joakim Bech proposed something similar, with more details > about how this was implemented for OP-TEE. > >> Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. > > Sorry I didn't get this, could you please elaborate? > >> Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. >> If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). > > If there's no appropriate tag in some cases, I guess we could always use > a git SHA1 of a specific commit. > >> Life Cycle State >> >> Fully Supported >> There is (at least) one active code owner for this platform. >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues are tracked >> Documentation is up to date >> >> Note: Projects should document standards on how "active" code ownership is measured and >> further document standards on how code owners are warned about impending life cycle state changes. > > Yes, good point, that is currently undefined in the proposal but I agree > that it needs defining per project. I will add an item in the last > section of the document. > > I am starting to think that we need a list of items to be defined per > project. This list would complement the general tf.org proposal. Things > like code owners/maintainers activity, code review timelines, and so on. > >> >> Orphan >> There is no active code owner >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) >> Documentation status is unclear since there is no active code owner. >> There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" > > I am confused, you said earlier that you would like to see the concepts > of support and functionality split out, but here you're listing 'orphan' > as one of the possible states... Did I miss your point? > >> Out of date >> Same as orphan, but either: >> there have been changes to the feature/functionality list, or >> there are failing tests without tracked tickets, or >> there are known documentation issues. >> >> Deprecated >> Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. >> >> Erik Shreve, PSEM >> Software Security Engineer & Architect (CMCU Platform Development)

5 years, 6 months

1
0
0 0

Patches to remove fixed NS region numbers

by Jamie Fox

Hi all, I am proposing some patches to move away from using fixed NS region numbers defined by TF-M core, to having platform-defined SAU region numbering. The motivation for the change is to give platforms more flexibility when configuring the isolation hardware, and in particular, to make it possible to use tools like CMSIS-Zone to generate the isolation hardware configuration. There are a couple of patches: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3484 -- Removes the memory permission check API from TF-M, which was the only user of the fixed region numbers. This API is no longer required because the SPM does all necessary memory permission checks before control reaches the secure partition. The patch removes uses of this API from the Attestation service, the platform service and the tests. https://review.trustedfirmware.org/c/trusted-firmware-m/+/3485 -- Removes the fixed region numbers and refactors all platforms to no longer use them. Reviews appreciated. Kind regards, Jamie

5 years, 7 months

1
0
0 0

Re: [TF-M] Renaming SST to PS

by Andrej Butok

Finally it will be fixed. It was confusing for new people, Thank you ;) From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, April 3, 2020 8:04 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Renaming SST to PS Hi, Please be aware that there is a ongoing change<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> to rename the SST (Secure STorage) service to PS (Protected Storage). This is to align with the PSA Storage API spec. The SST service is the implementation of the PSA Protected Storage service. The change renames lots of files, API names, build configurations etc... Lots of impacts are expected. Please do get prepared. Another notice after merging the change will be sent too. And, comments are always welcomed. Best Regards, Kevin

5 years, 7 months

1
0
0 0

Renaming SST to PS

by Kevin Peng

Hi, Please be aware that there is a ongoing change<https://review.trustedfirmware.org/c/trusted-firmware-m/+/3597> to rename the SST (Secure STorage) service to PS (Protected Storage). This is to align with the PSA Storage API spec. The SST service is the implementation of the PSA Protected Storage service. The change renames lots of files, API names, build configurations etc... Lots of impacts are expected. Please do get prepared. Another notice after merging the change will be sent too. And, comments are always welcomed. Best Regards, Kevin

5 years, 7 months

1
0
0 0

Re: [TF-M] mcmse option to compile non secure image

by Tamas Ban

Hi, Perfect timing! Please check this change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3592 There is no reason, the above change fix it. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Cindy Chaumont via TF-M Sent: 02 April 2020 20:01 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] mcmse option to compile non secure image Hello, I have been working for a few weeks with the Trusted Firmware M software and I was wondering a question to which I cannot find an answer. This concerns CMSE, I thought the -mcmse option should only be used to compile secure images (http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_pge144464730…). However, it seems to me that the non secure image of TF-M is also compiled with the -mcmse option. Is there a reason for this? Thank you in advance for the answer, Best regards, Cindy Chaumont (Intern in embedded computing at Witekio)

5 years, 7 months

1
0
0 0

mcmse option to compile non secure image

by Cindy Chaumont

Hello, I have been working for a few weeks with the Trusted Firmware M software and I was wondering a question to which I cannot find an answer. This concerns CMSE, I thought the -mcmse option should only be used to compile secure images (http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_pge144464730…). However, it seems to me that the non secure image of TF-M is also compiled with the -mcmse option. Is there a reason for this? Thank you in advance for the answer, Best regards, Cindy Chaumont (Intern in embedded computing at Witekio)

5 years, 7 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by DeMars, Alan

Is pre-emption while in secure mode supported? If so, NS RTOS may have to be modified to handle switching from a thread who's PC and SP are in secure domain. How would a secure service thread block while waiting for a security-protected hardware process to finish (ie what is the secure driver model)? Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 2, 2020 5:49 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Really great to see your involvement. Let me share my view on a TF-M execution model for constrained single core v8-M with TrustZone using Secure Function Call (aka library) mode: On secure side: single thread execution only. Not stack swapping. NS to S calls are blocking until secure execution completes. On non-secure side: RTOS with threaded execution. Entry to secure side protected with Mutex. This structure is explain on page 27 of https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS_Review_Meeting_2… IMHO, there are various benefits: * Overall less complexity, no need of tz_context, any RTOS would work, less memory overhead (i.e. single stack at secure side) * No impact to time deterministic execution on the NS side unless two threads call secure services * Conflict of mulitple threads calling secure services could be minimized with RTOS that offers priority inversion Are there any obvious problems with the above model? Thanks Reinhard Keil - Sr. Director Embedded Tools, Arm P.S. maybe you read also https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html IMHO we need to simplify the NS to S call entry to speed-up the overall system

5 years, 7 months

2
6
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Ken Liu

Hi, Looks like another non-secure thread with higher priority could not access secure service since the secure context belongs to previous ongoing non-secure thread and tz_context is not proposed? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 2, 2020 9:52 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

5 years, 7 months

1
0
0 0

Multi-threaded single-scheduler model proposal

by Reinhard Keil

Hi Erik, Really great to see your involvement. Let me share my view on a TF-M execution model for constrained single core v8-M with TrustZone using Secure Function Call (aka library) mode: On secure side: single thread execution only. Not stack swapping. NS to S calls are blocking until secure execution completes. On non-secure side: RTOS with threaded execution. Entry to secure side protected with Mutex. This structure is explain on page 27 of https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS_Review_Meeting_2… IMHO, there are various benefits: * Overall less complexity, no need of tz_context, any RTOS would work, less memory overhead (i.e. single stack at secure side) * No impact to time deterministic execution on the NS side unless two threads call secure services * Conflict of mulitple threads calling secure services could be minimized with RTOS that offers priority inversion Are there any obvious problems with the above model? Thanks Reinhard Keil - Sr. Director Embedded Tools, Arm P.S. maybe you read also https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html IMHO we need to simplify the NS to S call entry to speed-up the overall system

5 years, 7 months

1
0
0 0

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

by Sandrine Bailleux

Hi Joakim, On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: > Hi Christian, Sandrine, all, > > On Thu, Mar 26, 2020 at 10:27:14AM +0100, Sandrine Bailleux wrote: >> Hi Christian, >> >> Thanks a lot for the read and the comments! >> >> On 3/25/20 7:05 PM, Christian Daudt wrote: >>> ï¿½The maintenance proposal looks great ! I have some feedback on >>> specific portions: >>> ï¿½1. maintainer/owner/author patches. " Note that roles can be >>> cumulative, in particular the same individual can be both a code owner >>> and a maintainer. In such a scenario, the individual would be able to >>> self-merge a patch solely affecting his module, having the authority to >>> approve it from both a code owner and maintainer's point of view.": I'm >>> always leery of people self-approving their patches. At a minimum, all >>> self-patches should be published and a minimum wait time provided for >>> feedback. Or preferably that another maintainer does the merge (it does >>> not need to be mandated but should be suggested). >> >> Yes, actually this is something that generated some disagreement inside Arm >> as well and I am glad you're bringing this up here, as I'd like to hear more >> opinions on this. >> >> I too have concerns about allowing self-reviewing. I am not so much >> concerned about people potentially abusing of this situation to silently >> merge patches, as I think we should trust our maintainers. But I am worried >> that a self-review is rarely as good as a peer review, simply because it is >> so easy to miss things when it's your own work. I believe several pair of >> eyes is always better, as different people think differently, have different >> perspectives and backgrounds, and are able to catch different issues. >> >> But to pull this off, we need enough people to do all these reviews. The >> proposal currently allows self-review because some of us feared that >> mandating 2 reviewers for every patch (especially pure platform patches) >> would be impractical and too heavyweight, especially for the TF-M project in >> its current contributors organization, as I understand. It would be great to >> get more feedback from the TF-M community as to whether they think it could >> work in the end. >> >> It's a difficult balance between having the best possible code review >> practices, and realistically getting all the review work done in a timely >> manner, avoiding bottlenecks on specific people and keeping the flow of >> patches smooth. >> >> I like your idea of a minimum wait time provided for feedback. I think it >> could be a good middle ground solution. >> > +1 for that, after silence for X weeks it should be OK to merge the > patch. X would need to be number that is high enough for people to have > a chance to find it and look into it, but shouldn't be too high, since > there is a risk that it'll force the contributor to pile up things that > might be dependent on this patch. To throw something out, I'd say ~2 > weeks sounds like a good number to me. > >> Your other suggestion of having a different maintainer doing the merge would >> work as well IMO but requires more workforce. Again this comes down to >> whether this can realistically be achieved for each project. This solution >> was actually suggested within Arm as well (and even called out at the end of >> the proposal ;) ). >> >> Bottom line is, in an ideal world I would like to condemn self-review >> because I consider this as bad practice > +1 > >> , but I do not know whether this will >> be practical and will work for TF-M as well. >> >>> ï¿½2. 'timely manner': This expectation should be more explicit - when >>> the author can start requesting other maintainers to merge on assumption >>> that silence == approval (or not). Such timeliness expectations are >>> probably best set per project however. >> >> Yes, "timely manner" is definitely too vague and was actually left that way >> on purpose at this stage to avoid touching upon what I think is a sensitive >> subject! I am aware that some patches sometimes spend a long time in review, >> definitely longer than they should and it understandably generates some >> frustration. This is something we absolutely need to improve on IMO and >> hopefully a bigger pool of maintainers will help solve this issue. But I >> agree that the expected review timeline should be clearly established and it >> is probably best to let each project decides theirs. >> >>> ï¿½3. The proposal does not address branching strategies. i.e. will >>> there be separate maintainers for dev/master/stable branches? I don't >>> think it needs to address it yet - keep it simpler for a start. But a >>> todo saying something like "in the future this project maintenance >>> proposal might be expanded to address multi-branch maintainership" would >>> be good. >> >> Good point. A todo sounds good, I will add one in the last section of the >> document. >> >>> ï¿½4. The platform lifecycle state machine has too many transitions. >>> "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. >> >> Hmm OK. There might be too many transitions but I feel we need something >> between fully maintained and out, i.e. the limited support one. >> >> Julius Werner also pointed out on Thursday that orphan might be misplaced, >> as all these other stages deal with some degrees of feature support (what's >> known to work), whereas orphan is an orthogonal topic that is not directly >> related to the level of supported features. For example, a platform could >> have recently become orphan but all features and tests still work for some >> time. >> > At one point in time in the OP-TEE project we tried to keep track of > maintained platforms, by simply saying maintained "Yes" if they are > maintained. However they're not maintained, we indicated that by stating > the last known version where a platform was maintained. People can still > find that information here [1] (not up-to-date). The intention was to > give future users of an old platform a chance to know if it ever has > been supported and what version that was. That could serve as a starting > point in case someone is interested in bring a device/platform back to > life. Yes, I think such information can be very useful. It saves some "git archeology" effort to try and dig this information afterwards. Also, when someone starts looking at a project, I would expect this to be one of the first thing they look up, they would want to know in which shape the project is for the particular platform they are interested in. That's almost as important in my eyes as a "getting started" guide. We could have such a high-level table that just says whether a platform is supported or not (just a yes/no) and have complementary, per-platform documentation that goes into the details of what features are supported exactly. > How that works in practice is that all OP-TEE maintainers are adding > their "Tested-by" (see example [2]) tag for the platform they maintain > when we're doing a release. If there are platforms with no "Tested-by" > tag, then they simply end up with the "last known version". I think that's a very good idea! > However, to keep that up-to-date, it requires some discipline from the > people maintaining such a table ... something that we in the OP-TEE > project haven't been very good at :) Can't this be automated, such that it doesn't need to be manually kept up-to-date? I imagine we could have some tools generating the platform support table out of such a commit message. > So, I'm not proposing something, it's just that I wanted to share what > we've tried and it "works", but not easy to maintain (a release > checklist could fix that). > > [1] https://optee.readthedocs.io/en/latest/general/platforms.html > [2] https://github.com/OP-TEE/optee_os/pull/3309/commits/765b92604459240bed7fcf… >

5 years, 7 months

2
1
0 0

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

by Shreve, Erik

Sandrine, Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. I'd like to see these split out. For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. Here is a more concrete proposal: Functional Support: Each project shall provide a standard feature or functionality list. Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. The platform documentation may reference a ticket if support is planned but not yet present. The platform documentation shall explicitly state if a feature or function has no plans for support. The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). Life Cycle State Fully Supported There is (at least) one active code owner for this platform. All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues are tracked Documentation is up to date Note: Projects should document standards on how "active" code ownership is measured and further document standards on how code owners are warned about impending life cycle state changes. Orphan There is no active code owner All supported features build and either all tests pass or failures are associated with tracked known issues. Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) Documentation status is unclear since there is no active code owner. There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" Out of date Same as orphan, but either: there have been changes to the feature/functionality list, or there are failing tests without tracked tickets, or there are known documentation issues. Deprecated Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Sandrine Bailleux via TF-M Sent: Tuesday, March 24, 2020 4:42 AM To: tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
2
0 0

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

by Christian Daudt

Hi Sandrine, > Please find the initial proposal here: > > https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… > > Please provide any feedback you may have by replying to this email > thread, keeping all 4 mailing lists in the recipients list. > > I will collate comments from the community and try to incorporate them > in the document, keeping you updated on changes made between revisions. The maintenance proposal looks great ! I have some feedback on specific portions: 1. maintainer/owner/author patches. " Note that roles can be cumulative, in particular the same individual can be both a code owner and a maintainer. In such a scenario, the individual would be able to self-merge a patch solely affecting his module, having the authority to approve it from both a code owner and maintainer's point of view.": I'm always leery of people self-approving their patches. At a minimum, all self-patches should be published and a minimum wait time provided for feedback. Or preferably that another maintainer does the merge (it does not need to be mandated but should be suggested). 2. 'timely manner': This expectation should be more explicit - when the author can start requesting other maintainers to merge on assumption that silence == approval (or not). Such timeliness expectations are probably best set per project however. 3. The proposal does not address branching strategies. i.e. will there be separate maintainers for dev/master/stable branches? I don't think it needs to address it yet - keep it simpler for a start. But a todo saying something like "in the future this project maintenance proposal might be expanded to address multi-branch maintainership" would be good. 4. The platform lifecycle state machine has too many transitions. "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Thanks, Christian. 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.

5 years, 7 months

3
2
0 0

Slight update on design proposal process document

by Ken Liu

Hi, I have made a slight update on the design proposal process document, to simplify the design document drafting. The 'Author' and 'Organization' are not both mandatory, one of them can be optional depends on the contributor. And mark the 'status' optional since it can be covered by the document system. Feel free to comment on the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3407 And I prefer to comment on the issue link since there is more better for discussion: https://developer.trustedfirmware.org/T673 Reply here is an option, too. BR /Ken

5 years, 7 months

1
1
0 0

TF-M v1.0 is released

by Anton Komlev

Dear All, Happy to announce that Trusted Firmware - M project has reached the important milestone of v1.0. The major features covered in this release are : * PSA Level 1 & Level 2 certification requirements as updatable RoT * Support for PSA Dev APIs (PS, ITS, Attestation) aligned to PSA 1.0 specs, and Crypto aligned to 1.0-beta-3 * Reference implementation on various platforms * Arm : Musca-A, Musca-B1, Musca-S1, FPGAs , FVPs * Cypress PSoC6 * ST's STM32L5 and NXP's LPC55S69 are coming soon All release details are in the changelog file: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/changelog.… A Rendered HTML version is here: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… This is the result of great collaboration between multiple organizations toward a single common goal - to make firmware secure and trustful. Thanks all direct and indirect contributors who devoted their time and efforts to make this happen. Anton Komlev TF-M Technical Leader Arm Ltd.

5 years, 7 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Shreve, Erik

Ken, Thanks for the feedback! I agree that care will be needed in the design and implementation of the calls from S to NS. I hope to provide design details that minimize the risk by minimizing the RTOS specific layer. Unfortunately, I'm not clear on your feedback about the 'scheduler' and 'context-switch' terms. Let me expand on my proposal here a bit more. Perhaps this will clarify things or at least provide enough detail for you to provide more specific feedback. I'm sure you are aware that the PSA Firmware Framework provides for the scheduling of the secure partitions. I'm proposing (as an option, it is not a core feature of the proposal) that the SPM may be responsible for scheduling of Application Root of Trust services in this new model. Further, execution of PSA RoT services on behalf of Application RoT services may also fall under the SPM's scheduling. Thus, this part of the new model would fit with the PSA FF spec. This would thus mean that the NSPE RTOS is only scheduling NSPE Tasks and the associated PSA RoT service requests for those NSPE Tasks. However, supporting the "App RoT scheduling by SPM" in the model may complicate the implementation or at the very least the straightforward understanding of how the model works. The alternative, of course, is that the NSPE RTOS schedules the execution of the Application RoT services the same as it schedules the PSA RoT services. I think I prefer the latter, but I'm open to the former if the community has good reasons for it. One reason might be an expectation that PSA RoT services will be maintained by platform owners and platform owners can choose which models to support, but the community may want creators of Application RoT services to have the same experience regardless of the model implemented. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Monday, March 23, 2020 9:49 PM To: 'tf-m(a)lists.trustedfirmware.org' Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, This is a good proposal, thanks. And I got two comments in your listed bullets: * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) - Even the Trustzone-M supports S to NS call, be cation when you are designing such features because leave a waiting pattern in the secure side exposes one extra interface. * A SPE scheduler may still exist for application root of trust services, if any exist on a system. - Please use the 'scheduler' and 'context-switch' with scope. If there are 2 threads only and just switching contexts between them, the word 'scheduler' would be a bit confusing here. Hope my assumption is incorrect. Please go ahead with your preparation for the Tech Forum. Anton can give you detail descriptions about it and I think preparing a PUBLIC slide can be the first step. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Tuesday, March 24, 2020 5:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

2
1
0 0

Invitation: TF-M Tech Forum @ Thu 2 Apr 2020 16:00 - 17:00 (BST) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum After a discussion on the mailing list we have moved the timeslot this week to give an opportunity for US participants to join.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: Thu 2 Apr 2020 16:00 – 17:00 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=NmY2dWZkbzZtMjZyNHNmb… 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, 7 months

1
0
0 0

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

by David Wang

That sounds good! Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, March 24, 2020 1:46 AM 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 Technical Forum call - April 2 Hi Jamie, Thanks for noticing. You are right, that time would be better so the new proposal is 15.00 UTC. I have reused the time from the last session but forgot about the time change. Here anyone can play with the time zones: https://www.timeanddate.com/worldclock/meetingtime.html?day=2&month=4&year=… Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Thursday, 2 April 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, 2 April 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, 2 April 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, 2 April 2020, 23:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 2 April 2020, 15:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200402T1500> Best regards, Anton From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: 23 March 2020 17:29 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: TF-M Technical Forum call - April 2 Hi Anton, As we will have moved to daylight saving time in US and Europe, it seems like 15.00 UTC could be a good compromise for this next session. Would result in 8.00 west coast/10.00 central/11.00 east/16.00 UK/17.00 Europe/23.00 China. So good times for US/Europe and still possible for China to join if anyone really wants to. What do you think? Kind regards, Jamie 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: 23 March 2020 14:30 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 2 Hello, Last 3 sessions of the Tech Forum were convenient for Europe – Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

1
0
0 0

Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine

5 years, 7 months

1
0
0 0

Re: [TF-M] TF-M Profile Small design document under review

by Andrej Butok

Hi David, I have attached the Mbed-Crypto configuration file, which enables only minimum set of crypto algorithms required to pass the current TFM regression tests. It saves us about 30KB of ROM if to compare to the default TFM settings. Hope, it can be useful for others. Regards, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, March 24, 2020 7:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Profile Small design document under review Hi all, Could you please help review the latest design document of TF-M Profile Small (previously named as Profile 1)? TF-M Profile Small provides a predefined list of features with small memory footprint, on ultra-constrained device. Major changes since last version: * Renamed as Profile Small to avoid confusing readers with other similar terms. The other profiles will be named as Profile Medium and Profile Large. * Enable symmetric key algorithms based Initial Attestation. Please help review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> for more details. The corresponding implementation patch set is also updated on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Any suggestion or comment is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Friday, March 6, 2020 4:47 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 Profile 1 design document under review Hi all, As we discussed in Tech Forum yesterday, we proposed the TF-M Profile 1 design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Any comment, suggestion or question is welcome. We will keep updating and finalizing the document. The corresponding TF-M Profile 1 implementation patch set is also under review on https://review.trustedfirmware.org/q/topic:%22profile-1-config%22+(status:o…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>. Best regards, Hu Ziji

5 years, 7 months

2
1
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Anton Komlev

Hi Erik, Right, I had in mind the next forum on Apr 2, which is planned for US time zone. Invitations will be send soon having no more ideas or objection on the time slot. The forum format is open and quite unformal. You can find the recordings of all sessions here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ I would suggest to have few slides with the concept for idea introduction and references during discussion. All the best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 21:26 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

TF-M Profile Small design document under review

by David Hu

Hi all, Could you please help review the latest design document of TF-M Profile Small (previously named as Profile 1)? TF-M Profile Small provides a predefined list of features with small memory footprint, on ultra-constrained device. Major changes since last version: * Renamed as Profile Small to avoid confusing readers with other similar terms. The other profiles will be named as Profile Medium and Profile Large. * Enable symmetric key algorithms based Initial Attestation. Please help review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598 for more details. The corresponding implementation patch set is also updated on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Any suggestion or comment is welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Friday, March 6, 2020 4:47 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Profile 1 design document under review Hi all, As we discussed in Tech Forum yesterday, we proposed the TF-M Profile 1 design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Any comment, suggestion or question is welcome. We will keep updating and finalizing the document. The corresponding TF-M Profile 1 implementation patch set is also under review on https://review.trustedfirmware.org/q/topic:%22profile-1-config%22+(status:o…. Best regards, Hu Ziji

5 years, 7 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Ken Liu

Hi Erik, This is a good proposal, thanks. And I got two comments in your listed bullets: * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) - Even the Trustzone-M supports S to NS call, be cation when you are designing such features because leave a waiting pattern in the secure side exposes one extra interface. * A SPE scheduler may still exist for application root of trust services, if any exist on a system. - Please use the 'scheduler' and 'context-switch' with scope. If there are 2 threads only and just switching contexts between them, the word 'scheduler' would be a bit confusing here. Hope my assumption is incorrect. Please go ahead with your preparation for the Tech Forum. Anton can give you detail descriptions about it and I think preparing a PUBLIC slide can be the first step. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Tuesday, March 24, 2020 5:26 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Shreve, Erik

Anton, Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc. Thanks! Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Anton Komlev

Hi Erik, Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects. Let me know, please, if you want to include this topic into next forum agenda? Kind regards, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

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

by Jamie Fox

Hi Anton, As we will have moved to daylight saving time in US and Europe, it seems like 15.00 UTC could be a good compromise for this next session. Would result in 8.00 west coast/10.00 central/11.00 east/16.00 UK/17.00 Europe/23.00 China. So good times for US/Europe and still possible for China to join if anyone really wants to. What do you think? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 23 March 2020 14:30 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - April 2 Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

2
1
0 0

TF-M Technical Forum call - April 2

by Anton Komlev

Hello, Last 3 sessions of the Tech Forum were convenient for Europe - Asia time zones, where majority of participants are. To let US members a chance to join at a reasonable time, propose to have the next session at US-friendly time (17:00 UTC) and then keep it every 4th, having 1:3 ratio. What do you think about such schema? As usual, please reply to this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 7 months

1
0
0 0

Multi-threaded single-scheduler model proposal

by Shreve, Erik

I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system. I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed. 1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler. A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code. I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why? I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first. Thanks, Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243

5 years, 7 months

1
0
0 0

Trusted Firmware Keynote @Linaro TechDays (Wed 25 Mar, 16:00-16:30 GMT)

by Shebu Varghese Kuriakose

Hi All, Trusted Firmware will be opening the Linaro Tech Days event on Wed 25th March at 4pm (16:00) GMT with a keynote presenting all the latest exciting news from the project. https://connect.linaro.org/resources/ltd20/ltd20-200k/ and, once registered, on sched: https://linarotechdays.sched.com/event/ZZFK/ltd20-200k-keynote-trusted-firm… The session will be live streamed and recorded (links in the above resources) and slides will be attached there too. Don't miss it! Regards, Shebu/Matteo

5 years, 7 months

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, For your 2nd question. I have tested it on my side and it has the same problem. The TF-M can print normal boot message, but the log becomes garbage after enter into Arch test. The PSA Arch test is another independent project, and I have arisen this issue to the PSA Arch test project: https://github.com/ARM-software/psa-arch-tests/issues/164. You can watch this issue directly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Thursday, March 19, 2020 9:54 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] psa-arch-tests console baud rate Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? 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>

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: SPM_IDLE

by DeMars, Alan

Ken, Our secure callback solution to this issue is working. I am just following up to understand what the SPM_IDLE concept is. Alan On Mar 20, 2020, at 4:34 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, Looks like this is the still classic case, but unfortunately that there is no defined design at the current stage. Heard you were working on an solution for this, and got some issues when non-secure preempts secure execution, since your scheduler works in thread mode so cannot update secure context while scheduling – please correct me if my understanding is wrong. Is this mail a follow up or another thread just focus on discussion of the cooperative scheduling document? BR /Ken From: DeMars, Alan <ademars(a)ti.com> Sent: Friday, March 20, 2020 2:27 AM To: Ken Liu <Ken.Liu(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: RE: SPM_IDLE Ken, Our use case is to support a “secure driver”: 1. A peripheral can only be accessed in secure mode. 2. The peripheral is configured and a hardware process is triggered within the peripheral. 3. When the process completes, a secure interrupt is triggered. 4. The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] SPM_IDLE Mention is made to “SPM_IDLE” in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I’m struggling to understand section 8.3.5 which references SPM_IDLE but doesn’t really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Interface: Remove unused header include

by Devaraj Ranganna

Hi, The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3620 removes the header `tfm_veneers.h` from PSA IPC API source files. If there are no objects then can this patchset be merged? Thanks, Dev 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, 7 months

1
0
0 0

Re: [TF-M] SPM_IDLE

by DeMars, Alan

Ken, Our use case is to support a "secure driver": 1) A peripheral can only be accessed in secure mode. 2) The peripheral is configured and a hardware process is triggered within the peripheral. 3) When the process completes, a secure interrupt is triggered. 4) The NS thread that is using this driver should block (allowing other NS threads to run) while waiting for the hardware process to complete and resume when the process is finished. Alan From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Thursday, March 5, 2020 10:28 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SPM_IDLE Hi Alan, It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, March 4, 2020 10:51 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SPM_IDLE Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called. Alan

5 years, 7 months

2
1
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Raymond Ngun

Thanks Tamas, Did you try with CC312 disabled as well? I am wondering if you would be able to at least reproduce what I saw. Ray From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Thursday, March 19, 2020 4:30 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: 2048-bit RSA Keypair generation is slow CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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. 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] psa-arch-tests console baud rate

by Edison Ai

Hi Thomas, Thanks your mail. For your 1st question. There is indeed a problem to build the PSA arch crypto test on the Musca_a board for the RAM size is too small. I suggest you split the crypto tests into different test images on the Musca_a board. For the 2nd question, I only test that on FVP AN521 but never met this problem. We will test that on the MPS2 AN521 board soon to check if it is a real problem. If yes, we will try to fix that quickly. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, March 18, 2020 9:38 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa-arch-tests console baud rate Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? 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>

5 years, 7 months

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

Note that you'll still to re-seed from the TRNG periodically, but doesn't have to be done every time the application needs a random number. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 19 March 2020 11:16 To: Raymond Ngun <Raymond.Ngun(a)cypress.com>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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, 7 months

1
0
0 0

FW: 2048-bit RSA Keypair generation is slow

by Tamas Ban

Hi, We did measurements on Musca-B1 with enabled CC312. We did 10 run with both compiler( armclang and gnuarm). RSA2048 key generation takes 10-35 sec. In average gnuarm seems a bit slower. I suspect the reason behind that random number still need to be tested that are they fit for rsa2048 generation (might are they primes?) and the testing algorithm is might faster with armclang. But for sure we have not seen any run which could take minutes. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Adrian Shaw via TF-M Sent: 19 March 2020 12:17 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That's all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn't test Musca-B1 with cc312 enabled and I don't have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn't always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I've seen it finish quickly (less than a minute) but I've also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Adrian Shaw

If the platform has on-chip NVM then you should consider using NV seed entropy. You still need a TRNG to get the initial entropy, but seems like it could improve average runtime performance. I believe there's a macro like MBEDTLS_ENTROPY_NV_SEED that you have to enable, as well as providing the hooks to read/write the flash. Adrian ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 18 March 2020 16:24 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] 2048-bit RSA Keypair generation is slow Hi Ray, That is good information. The software RNG is not truly random and is not production quality. The predictable timing could be an indicator that the randomness is reproducible. That’s all I know, but the mbed-crypto team may have more inputs and they can be queried here : https://github.com/ARMmbed/mbed-crypto/issues Best Regards Soby Mathew From: Raymond Ngun <Raymond.Ngun(a)cypress.com> Sent: 18 March 2020 15:33 To: Soby Mathew <Soby.Mathew(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Soby, Musca-B1 has CC312 support which will introduce an rng for this purpose. Unfortunately, I didn’t test Musca-B1 with cc312 enabled and I don’t have a board now to test with. However, I did test with a h/w rng on the PSoC64 and the performance isn’t always better. When using s/w, the time it takes was quite consistent at 1.5 minutes or 5.5 minutes depending on toolchain. After introducing the h/w rng, I’ve seen it finish quickly (less than a minute) but I’ve also seen it take 15 minutes. Thanks, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, March 18, 2020 4:44 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com<mailto:Raymond.Ngun@cypress.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: 2048-bit RSA Keypair generation is slow Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I’ve run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I’ve seen it take even longer – I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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. 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] 2048-bit RSA Keypair generation is slow

by Soby Mathew

Hi Raymond Thanks for bring this to the forum. When I did the migration to the latest mbed-crypto tag, I faced the same issue. After couple of discussion within the team and mbedcrypto, this is the understanding I have. Currently mbedcrypto is configured to use NULL entropy. Hence this is the print message when building mbedcrypto : #warning "**** WARNING! MBEDTLS_TEST_NULL_ENTROPY defined! " This means that mbedcrypto uses a software algorithm to generate randomness. It iterates this algorithm till it can generate enough randomness for the keypair generation and this is the reason for the delay. If the hardware has an entropy source which can be used for this random number generation, then I understand the performance will be much better. But this will need suitable configuration to be enabled from TF-M. I am not much familiar with hardware architecture of M-Class systems. One of the questions I have to the forum is, do we have such entropy sources on the hardware? Then it is worth scheduling some task to investigate how to abstract/use the entropy source. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 17 March 2020 21:02 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] 2048-bit RSA Keypair generation is slow Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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.

5 years, 7 months

2
2
0 0

psa-arch-tests console baud rate

by Thomas Törnblom

Triggered by Rays mail on slow RSA key pair generation, I built and tried to run the tests, but ran into a couple of issues: 1) I attempted to build it for the Musca A, but apparently that doesn't have enough RAM to run these tests 2) Switching to an MPS2+ with AN521 configuration I see that the baud rate on the UART appears wrong when running the tests. mcuboot produces correct messages at 115200 bps, as does the normal ConfigRegression* tests, but the ConfigPsaApiTest* appears to produce just garbage. Is there a setting I need to set to get any useful data on the terminal when running the ConfigPsaApiTests? 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>

5 years, 7 months

1
0
0 0

2048-bit RSA Keypair generation is slow

by Raymond Ngun

Hi all, When testing the PSA API Crypto Dev API test suite, I noticed that psa_generate_key() is awfully slow when generating a 2048-bit RSA keypair and the performance is different depending on toolchain used. I've run these tests on Musca-B1 and with GCC, key generation generally completes in 25s but an armclang build requires 2.5 minutes to complete. This is more pronounced on PSoC64 where we are building for armv6m. Here, the key generation can take up to 5.5 minutes and I've seen it take even longer - I assume this is due to values returned by rng. Anybody have comments on the performance of psa_generate_key() or more specifically mbedtls_rsa_gen_key()? What can be done to help improve the performance of this software implementation? 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.

5 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M