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/==…Topic:
TF-M Tech forum - Asia Time Zone FriendlyTime: Nov 12, 2020 07:00 AM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 4, 2021, 5 occurrence(s) Nov 12, 2020 07:00
AM Dec 10, 2020 07:00 AM
Jan 7, 2021 07:00 AM Feb 4, 2021 07:00
AM Mar 4, 2021 07:00 AMPlease download and
import the following iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT09Meeting
ID: 925 3579 4925Passcode: 414410One tap mobile+12532158782,,92535794925#
US (Tacoma)+13462487799,,92535794925# US (Houston)Dial by your
location +1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose) +1 301 715
8592 US (Germantown) +1 312 626 6799 US
(Chicago) +1 646 558 8656 US (New York)
888 788 0099 US Toll-free
877 853 5247 US Toll-freeMeeting ID: 925 3579 4925Find your local number:
https://linaro-org.zoom.us/u/aesS64I7GW
When: Every 4 weeks from 12am to 1am on Thursday from Thu Nov 12 to Fri May
28, 2021 Mountain Standard Time - Phoenix
Where:
https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* tf-m(a)lists.trustedfirmware.org
* anton.komlev(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NTAyYXB1M2xsYzJ2MzU3M…
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 organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hello,
The next Technical Forum is planned on Thursday, October 29 (for US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://review.trustedfirmware.org/q/topic:%22linker_script_isolation%22+(s…>
* Isolation HAL API<https://review.trustedfirmware.org/q/topic:%22isolation_api_implementation%…>
* SPM log<https://review.trustedfirmware.org/q/topic:%22SPM_LOG%22+(status:open%20OR%…>
* SP log<https://review.trustedfirmware.org/q/topic:%22tfm_sp_log%22+(status:open%20…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4829>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi,
Thank Tamas for the scenario, this is a good example.
There were some queries and initial investigations before, which shows that some users want to protect the implementation of their services, and check if there are mechanisms to help on that. I think isolation level 3 is applicable to this scenario.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Wednesday, October 21, 2020 7:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Andrej,
the following scenario comes to my mind:
* There is a product where secure services from different vendors are merged together and these are together make up the ARoT code.
* There is a vendor who has a novel algorithm what he wants to protect against reverse engineering.
* Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot.
* This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code.
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: 2020. október 21., szerda 11:53
To: Kevin Peng <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Andrej,
the following scenario comes to my mind:
* There is a product where secure services from different vendors are merged together and these are together make up the ARoT code.
* There is a vendor who has a novel algorithm what he wants to protect against reverse engineering.
* Image is delivered to the device in encrypted format. But on the device it is decrypted when moved to primary slot.
* This secure partition needs the L3 isolation to be hidden from the other secure services within ARoT code.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 2020. október 21., szerda 11:53
To: Kevin Peng <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Kevin,
Do you know any real (not academic) MCU application where L3 isolation is required?
People ask, but I have nothing to tell. Even for L2 is difficult to find something, for most of cases L1 is enough.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Wednesday, October 21, 2020 11:27 AM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi all,
We've finished the PoC of isolation level 3 along with the new TFM HAL on the feature branch.
And now we are migrating the patches to master branch by cherry-picking, squashing and refining.
Here are the several topics ongoing parallel:
* Linker script changes for isolation L3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* Isolation HAL API<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SPM log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
* SP log<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
And the HAL API docs:
* Docs: Design of the TF-M isolation HAL<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
More patches will be coming soon, will keep you update-to-date.
Please help on reviews, thanks.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Wednesday, September 9, 2020 3:21 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] Feature branch 'feature-isolation-level3' is created for related patches merging
Hi,
A new branch created for two repos 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m', this feature branch is for isolation related patches merging.
The POC patches would come in following days, first platform would be AN521. If you want to try this branch, please:
IMPORTANT:
Checkout 'feature-isoaltion-level3' branch for both 'TF-M/tf-m-tests' and 'TF-M/trusted-firmware-m'.
BR
/Ken
Hi Chris,
I've raised a ticket https://github.com/ARM-software/psa-arch-tests/issues/239 on PSA Arch test github repo. It will be fixed by PSA Arch test team later.
We will follow the fix status. Thanks again for reporting this issue.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, October 20, 2020 11:05 AM
To: Christopher Brand <chris.brand(a)cypress.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Another build issue
Hi Chris,
I agree with you. It looks like PSA arch test doesn't check the correct clone destination.
According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists.
However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets.
Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is.
I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed.
IMOO, the quick workaround is to entirely remove the build directory.
I will discuss with Raef to determine a final solution.
Thanks a lot for reporting this issue!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, October 20, 2020 5:57 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Another build issue
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.
Hi Anton
If it's not possible to avoid a file generation now, it's good to have pre-generated files for a most typical configuration (l2, IPC etc.).
As I mentioned before, ideally to use TFM as a real component/framework without generation of any source code.
BUT If you believe, this requirement breaks a TFM concept, just tell us.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, October 20, 2020 9:27 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Generated files location
Hi Andrej,
Essentially, do you mean to move the files back to code tree and synch them with templates manually as it was ?
Cheers,
Anton
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 19 October 2020 16:15
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: Generated files location
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
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: Monday, October 19, 2020 5:00 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] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi Anton,
Another option:
3. Avoid the mandatory on-the-fly generation.
Try to make TFM a component/framework, which is configurable by compile & run time parameters.
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Monday, October 19, 2020 5:00 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Generated files location
Hi,
Some source files in TF-M are templated and generated inside /<build_dir>/generated/ on the fly as a part of build process. This guaranty consistency between templates and generated but might make a trouble for IDE, where not all source files exist at the first run.
I see 2 options for solution:
1. Explicitly generate those files via cmake as a part of IDE project creation (1 time action)
2. Relay on CMSIS Pack for IDE, where generated files must be presents
Any alternative thoughts?
Anton
Hi Chris,
I agree with you. It looks like PSA arch test doesn't check the correct clone destination.
According to https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL…, PSA arch test checks whether psa_qcbor exists.
However, the actual clone destination of psa_qcbor folder is under CMAKE_CURRENT_BINARY_DIR as https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/CMakeL… sets.
Therefore, I guess this issue will be triggered as long as CMake script execution is in the different directory as binary folder is.
I changed the destination to ${CMAKE_CURRENT_BINARY_DIR}/${PSA_TARGET_QCBOR} in check step and it looks like the issue is fixed.
IMOO, the quick workaround is to entirely remove the build directory.
I will discuss with Raef to determine a final solution.
Thanks a lot for reporting this issue!
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M
Sent: Tuesday, October 20, 2020 5:57 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Another build issue
This one is a failure when re-configuring the build (even though the configuration is the same):
$ mkdir build_GNUARM_Release
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(lots of output - eventually succeeds)
$ cmake -S . -B build_GNUARM_Release -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=INITIAL_ATTESTATION
(less output, eventually fails)
fatal: destination path 'psa_qcbor' already exists and is not an empty directory.
CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:324 (message):
git clone failed for https://github.com/laurencelundblade/QCBOR.git
I suspect that this might be due to the PSA stuff, rather than TFM per se, but it manifests when building TFM...
Chris Brand
Sr Prin Software Engr, MCD: WIRELESS
Cypress Semiconductor Corp.
An Infineon Technologies Company
#320-13700 International Place, Richmond, British Columbia V6V 2X8 Canada
www.infineon.com<http://www.infineon.com> www.cypress.com<http://www.cypress.com>
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.