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

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] Create another branch for feature development

by David Wang (Arm Technology China)

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Kevin Peng (Arm Technology China)

Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

2
1
0 0

Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison

6 years, 1 month

1
0
0 0

Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by Ken Liu (Arm Technology China)

Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

6 years, 1 month

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

6 years, 1 month

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Jamie Fox

Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- 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: 28 November 2019 15:45 To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@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] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *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 <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:* 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:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? 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> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

6 years, 1 month

2
3
0 0

X.509 Certificate Chain Support in TF-M

by Kevin Townsend

Hi, As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing). The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device. At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval. - Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md - Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md - And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr… - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr… Specifically, they key missing aspects to enable the use of standard X.509 certificates are: - Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c… We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved. Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M. Best regards, Kevin Townsend

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M December 2019