- TF-M - lists.trustedfirmware.org

by Gernot Kvas

Hello, I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2]. What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated. Thanks for your help & kind regards, Gernot [1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf [2] https://developer.trustedfirmware.org/w/tf_m/planning/

5 years, 10 months

1
0
0 0

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

by Anton Komlev

Ups, please ignore this invitation with outdated subject. I have sent a better one. Sorry for confusion. Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 19 May 2020 13:58 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

5 years, 10 months

1
0
0 0

TF-M Technical Forum call - May 28

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

5 years, 10 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 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01: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, 28 May 2020, 07: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, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

5 years, 10 months

1
0
0 0

Re: [TF-M] PSA documentation page

by Ken Liu

Now we linked the home page (https://developer.arm.com/architectures/security-architectures/platform-sec…) of PSA in the readme (https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…), are you proposing to update to this documentation link? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Monday, May 18, 2020 6:12 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA documentation page For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

5 years, 10 months

1
0
0 0

[RFC] Compiler-specific configurations and architecture registers

by Summer Qin

Hi, Even the ongoing HAL design abstracts all platform-specific operations, there are still some operations that need to be performed directly in TF-M, such as architecture-related operations. These operations are common for all platforms, such as: * generic assembler code for AAPCS based context management. * assign attributes to specific functions. These operations rely on compiler and architecture much instead of the platform. So, define a CORE-specific compiler configuration header file would be a straight requirement. With these unified headers, writing the architecture-specific code would be much safer because it won't involve hardcode compiler related changes. The minimal set of mandatory architecture registers is also planned to be defined. Here send out a mail to collect for the feedbacks - is it worthy of doing this to decouple the architecture from the platform, or we can just re-use the platform provided headers? Any comments are welcome:) Best Regards, Summer

5 years, 10 months

1
0
0 0

PSA documentation page

by Adrian Shaw

For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

5 years, 10 months

1
0
0 0

Proposal to add sub-folders to collect documents under design_documents folder

by David Hu

Hi all, I'd like to propose to add sub-folders under docs/design_documents to collect the documents on the same topic. Currently, there are already 21 documents in total under docs/design_documents and the number may grow rapidly. It can be more clear if we can organize the documents on the same topic into a dedicated sub-folder under docs/design_documents. Please help review the patch set https://review.trustedfirmware.org/q/topic:%22design-doc-subdir%22+(status:… if the proposal sound interesting. I move dual-cpu and TF-M Profiles related documents to their dedicated folder respectively in the patches. Any comment is welcome! In current patches, the html pages are still put in the same level during Sphinx build. It is because design documents are grouped by document status, instead of document hierarchy. The html pages can be further organized as well if we switch to group html according to folder structures. Best regards, Hu Ziji

5 years, 10 months

1
0
0 0

Ask for final review of symmetric based initial attestation design

by David Hu

Hi all, May I ask for a final round of review on symmetric initial attestation design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3898? The document has been reviewed for a long time and received many valuable comments. Thanks a lot. If there is no further critical comment, I'd like to merge this design this Friday. Best regards, Hu Ziji

5 years, 10 months

1
0
0 0

[RFC] [Source Structure] Design document is availiable.

by Ken Liu

Hi, There is an upcoming source structure adjustment for TF-M. The basic idea is to make the structure simple and easy to be understood by users. The significant change would be a long term goal so no worry. In the beginning, there would be changes in core and platform to align with HAL changes. Please help to put comments on the design documents - after aligned, this document would be a user guide document to describe the source structure of TF-M. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4112 And the issue link: https://developer.trustedfirmware.org/T751 Feel free to put any comments or ask questions. Thanks. /Ken

5 years, 10 months

1
0
0 0

IRQ testing tool available for review

by Mate Toth-Pal

Hi All, The IRQ testing tool proposed for TF-M earlier, and presented in one of the TF-M tech forum is available for code review: https://review.trustedfirmware.org/c/trusted-firmware-m/+/4078/1 https://review.trustedfirmware.org/c/trusted-firmware-m/+/4079/1 The presentation can be viewed here: https://zoom.us/rec/share/3epSNYjX519Oeony5HH8WIgqXb7peaa82iYf_vZYmBuPbFktC… (Extended) Slides: https://www.trustedfirmware.org/docs/Automated_testing_of_interrupt_handlin… Please give feedback in gerrit review comments. Thanks, Mate

5 years, 10 months

1
0
0 0

Re: [TF-M] Attestation: is there an usage example for that somewhere

by Adrian Shaw

Hi Reinhard, Attestation is implemented in TF-M. There is a whitepaper here explaining attestation use cases and usage models https://www.psacertified.org/app/uploads/2020/02/PSA-Certified-Entity-Attes… The API is documented in the specification ARM IHI 0085, which you can find here https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im… Best, Adrian On 14 May 2020, at 15:55, Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Is Attestation already implemented? Is there somewhere information on how Attestation is used. I’m looking for user oriented information. Thanks for your help. Reinhard -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 10 months

1
0
0 0

Attestation: is there an usage example for that somewhere

by Reinhard Keil

Is Attestation already implemented? Is there somewhere information on how Attestation is used. I'm looking for user oriented information. Thanks for your help. Reinhard

5 years, 10 months

1
0
0 0

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

by Andrej Butok

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

5 years, 10 months

2
1
0 0

TF-M repository restructure

by Anton Komlev

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

5 years, 10 months

1
0
0 0

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

by Tamas Ban

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

5 years, 10 months

1
0
0 0

Boot seed in TFM Attestation tests

by Andrej Butok

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

5 years, 10 months

1
0
0 0

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

by Soby Mathew

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

5 years, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M