- TF-M - lists.trustedfirmware.org

Re: [TF-M] TF-M Technical Forum call – October 29

by Shawn Shan

Hi Anton, I would like to briefly introduce the update of TF-M log system, about 20 minutes. Best regards, Shawn From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, October 23, 2020 5:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call – October 29 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

5 years

1
0
0 0

Invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday from Thu Oct 29 to Fri Mar 26, 2021 (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

You have been invited to the following event. Title: 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/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# 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)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq When: Every 4 weeks from 8am to 9am on Thursday from Thu Oct 29 to Fri Mar 26, 2021 Mountain Standard Time - Phoenix Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… 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=NjQzcnZwcmEwNnV2cGoxN… 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

5 years

1
0
0 0

Invitation: TF-M Tech forum @ Every 4 weeks from 12am to 1am on Thursday from Thu Nov 12 to Fri May 28, 2021 (MST) (tf-m@lists.trustedfirmware.org)

by Don Harbin

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

5 years

1
0
0 0

TF-M Technical Forum call – October 29

by Anton Komlev

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

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Kevin Peng

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

5 years

1
1
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Ken Liu

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

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Tamas Ban

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

5 years

1
0
0 0

Re: [TF-M] Feature branch 'feature-isolation-level3' is created for related patches merging

by Andrej Butok

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

5 years

1
0
0 0

Re: [TF-M] Another build issue

by David Hu

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.

5 years

1
0
0 0

Re: [TF-M] Generated files location

by Andrej Butok

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

5 years

1
0
0 0

Re: [TF-M] Generated files location

by Andrej Butok

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

5 years

2
1
0 0

Re: [TF-M] Another build issue

by David Hu

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.

5 years

1
0
0 0

Another build issue

by Christopher Brand

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.

5 years

1
0
0 0

Re: [TF-M] Build failure

by Christopher Brand

Looks like that test is indeed not supported on PSoC64. The error message threw me because it says what the valid values are for -DTARGET (which does include one containing "psoc64"), but it doesn't tell me what -DTAREGT was actually set to. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Monday, October 19, 2020 1:42 PM To: David Hu <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build failure 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. We definitely used to be able to at least build ConfigPsaApiTestIPC.cmake (and the level 2 version) for PSoC64 under the old build system. It looks like we've always done so with one of the other PSA test suites also selected, which doesn't seem to be an option with the new build system. Is there an example TEST_PSA_API=IPC build for another platform I can look at? Chris From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Sent: Sunday, October 18, 2020 11:10 PM To: Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.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: Build failure Hi Chris, Sorry for the trouble. May I know if the same configurations worked with the previous build system? I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy? 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: Saturday, October 17, 2020 7:07 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Build failure I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". 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. 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.

5 years

1
0
0 0

Re: [TF-M] Build failure

by David Hu

Hi Chris, Sorry for the trouble. May I know if the same configurations worked with the previous build system? I checked a previous version of PSoC 64 specifics and it didn't explicitly claim to support FF compliance tests. Could you please confirm it with Alamy? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, October 17, 2020 7:07 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build failure I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". 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.

5 years

2
1
0 0

Generated files location

by Anton Komlev

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

5 years

1
0
0 0

Re: [TF-M] New build system missing GNUARM_PREFIX support

by Raef Coles

Hi, yes apologies that seems to have been lost. I was doing my best to track changes in the original cmake but it seems this one got missed. Can I ask - for the vendor triplet compilers (arm-etc-eabi-gcc), is it a compiler that the vendor is developing? In the new buildsystem, it might make sense to create a new compiler toolchain file that is almost identical to the GNU one, which would allow the two compilers to diverge slightly (in command-line options etc) if necessary. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 07 October 2020 17:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] New build system missing GNUARM_PREFIX support It looks like the GNUARM_PREFIX changes got dropped as part of the new build system. Can someone look at restoring those changes? - k -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years

2
2
0 0

Build failure

by Christopher Brand

I'm experimenting with the new build system, and seeing an error. Looking at docs/getting_started/tfm_build_instruction.rst, it mentions that TEST_PSA_API=IPC is a valid option ("Firmware Framework test suite"). When I try to configure for that build, though, I get an error: $ cmake -S . -B build_GNUARM_Release '-GUnix Makefiles' -DTFM_PLATFORM=cypress/psoc64 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=IPC CMake Error at build_GNUARM_Release/lib/ext/psa_arch_tests-src/api-tests/CMakeLists.txt:119 (message): [PSA] : Error: Unspported value for -DTARGET=, supported targets are : common;tgt_dev_apis_stdc;tgt_dev_apis_tfm_an521;tgt_dev_apis_tfm_an524;tgt_dev_apis_tfm_an539;tgt_dev_apis_tfm_musca_a;tgt_dev_apis_tfm_musca_b1;tgt_dev_apis_tfm_musca_s1;tgt_dev_apis_tfm_psoc64;tgt_ff_tfm_an521;tgt_ff_tfm_musca_a;tgt_ff_tfm_musca_b1 I see the same error with and without "-DTFM_ISOLATION_LEVEL=2". 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.

5 years

1
0
0 0

Security vulnerability notice - Secure stack sealing

by Soby Mathew

Hi Everyone There is a new security vulnerability report for Secure software executing on Armv8-M processors that causes it to be vulnerable to attacks from the Non-secure state if the secure stacks are not sealed properly. More details about the vulnerability can be found here: https://developer.arm.com/support/arm-security-updates/armv8-m-stack-sealing Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : 1. TF-M Security advisory https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6455/1 2. Fix based on TF-Mv1.1 release has been uploaded as a new branch "TF-Mv1.1-stack-seal-mitigation" to the main repository. The branch can also be accessed here: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=TF-Mv1.1… 3. Fix based on the latest master is available here: https://review.trustedfirmware.org/q/topic:%22stack-seal-mitigation%22. Please let us know if you have any comments. Best Regards Soby Mathew [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor…

5 years

1
0
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Tamas Ban

Hi Raymond, Test case 240, 241 are known limitation of cc312 driver. It is published here https://developer.trustedfirmware.org/T691 Tamas ________________________________ Feladó: TF-M <tf-m-bounces(a)lists.trustedfirmware.org>, meghatalmazó: Raymond Ngun via TF-M <tf-m(a)lists.trustedfirmware.org> Elküldve: 2020. október 15., csütörtök 20:29 Címzett: Soby Mathew <Soby.Mathew(a)arm.com>; Summer Qin <Summer.Qin(a)arm.com> Másolatot kap: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Tárgy: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Soby and Summer, Thank you for pointing me to the complete chain of patches. I didn’t notice. With this, PSoC64 behaves quite well without any buffer changes. In fact, the results look better than previously published AN521 results – what are the latest AN521 results? It looks like 250 and 251 now passes but failed in previous AN521 results. Again, this is for PSoC64 As for Musca-B1, it looks like it is better (CC312 enabled). 241/242 is still failing and 250 is failing (passes for PSoC64). Disabling CC312 will result in 241/242 passing Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Thursday, October 15, 2020 8:01 AM To: Summer Qin <Summer.Qin(a)arm.com>; Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, Some of the PSA Crypto tests require a larger buffer size and previously this was done within the build system. This size is required irrespective of IPC or Library mode. The new build system broke this buffer size configuration for API tests and the patch mentioned by Summer resolves that. Could you try with that and let us know ? Regarding Musca-B1, we switched to using Cryptocell as default for that platform recently. There are some limitations for the CC-312 with respect to some crypto APIs and I suspect the failures are related to this. I will create a ticket to look further into this. Meanwhile could you try whether you have failures if you disable CC-312 for Musca-B1 : diff --git a/platform/ext/target/musca_b1/config.cmake b/platform/ext/target/musca_b1/config.cmake index b343af36..47a2bfad 100644 --- a/platform/ext/target/musca_b1/config.cmake +++ b/platform/ext/target/musca_b1/config.cmake @@ -6,5 +6,5 @@ #------------------------------------------------------------------------------- set(PLATFORM_DUMMY_ATTEST_HAL FALSE CACHE BOOL "Use dummy boot hal implementation. Should not be used in production." FORCE) -set(CRYPTO_HW_ACCELERATOR ON CACHE BOOL "Whether to enable the crypto hardware accelerator on supported platforms" FORCE) +set(CRYPTO_HW_ACCELERATOR OFF CACHE BOOL "Whether to enable the crypto hardware accelerator on supported platforms" FORCE) set(TFM_CRYPTO_TEST_ALG_CFB OFF CACHE BOOL "Test CFB cryptography mode" FORCE) Best Regards Soby Mathew From: Summer Qin <Summer.Qin(a)arm.com<mailto:Summer.Qin@arm.com>> Sent: 15 October 2020 07:58 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; 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> Subject: Re: Behavior difference in Crypto IPC vs Library modes Hi Raymond, Do you cherry-pick all the series patches (topic: sm/new_build_crypto<https://review.trustedfirmware.org/q/topic:%22sm%252Fnew_build_crypto%22+(s…> ) or just only pick the one Soby provided? I testes on AN521, without all the series patches, 219, 241, 242, and 243 are failed. But when you cherry-pick all series patches, they can pass. And I think patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6251 already increase the size for CRYPTO_ENGINE_BUF_SIZE. Thanks, Summer ________________________________ 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 <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, October 15, 2020 6:54 AM To: 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> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Soby, Thank you for that fix! It does indeed fix this particular issue when using IPC. On another note, I’ve been running Musca-B1 and the results differ from what you sent out in the past for AN521. Specifically, Musca-B1 fails 219, 241, 242, and 243. Is this something you can have a look at on the Musca-B1 side? With that said, I’ve been running on PSoC64 and I can reproduce the AN521 results. I needed the patch you provided below but I was still running into memory issues and I had to bump the following (both of them). #define TFM_CRYPTO_IOVEC_BUFFER_SIZE (8120) #define TFM_CRYPTO_ENGINE_BUF_SIZE (0x5040) /* >8KB for EC signing in attest */ If I do not bump these, I would see 239 to 244 fail. Might you have any comments on the larger size requirements for these? Possibly when running in IPC mode? Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: Wednesday, October 14, 2020 8:52 AM 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> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, After further analysis, it seems to me that having separate checks for Library mode and IPC mode is the easiest way to go. The current design was done in such a way that both Library and IPC mode can reuse the same crypto service API involving IOVECs. Any change to how the API is invoked from the tfm_crypto_call_sfn() will have ramifications for Library mode. I have done a patch with different checks for IPC and Library mode here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6432 . The patch relaxes the checks for IPC mode to allow empty buffers and hardens the checks for Library mode. Hopefully this should resolve the issue. Best Regards Soby Mathew From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: 12 October 2020 17:17 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; 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> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew 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 Sent: 12 October 2020 11:50 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> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn’t get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. 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: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I’m seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I’ve been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I’m not sure if the check above is valid for IPC mode. I’ve removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. 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. 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

2
1
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Summer Qin

Hi Raymond, Do you cherry-pick all the series patches (topic: sm/new_build_crypto<https://review.trustedfirmware.org/q/topic:%22sm%252Fnew_build_crypto%22+(s…> ) or just only pick the one Soby provided? I testes on AN521, without all the series patches, 219, 241, 242, and 243 are failed. But when you cherry-pick all series patches, they can pass. And I think patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6251 already increase the size for CRYPTO_ENGINE_BUF_SIZE. Thanks, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raymond Ngun via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, October 15, 2020 6:54 AM To: 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] Behavior difference in Crypto IPC vs Library modes Hi Soby, Thank you for that fix! It does indeed fix this particular issue when using IPC. On another note, I’ve been running Musca-B1 and the results differ from what you sent out in the past for AN521. Specifically, Musca-B1 fails 219, 241, 242, and 243. Is this something you can have a look at on the Musca-B1 side? With that said, I’ve been running on PSoC64 and I can reproduce the AN521 results. I needed the patch you provided below but I was still running into memory issues and I had to bump the following (both of them). #define TFM_CRYPTO_IOVEC_BUFFER_SIZE (8120) #define TFM_CRYPTO_ENGINE_BUF_SIZE (0x5040) /* >8KB for EC signing in attest */ If I do not bump these, I would see 239 to 244 fail. Might you have any comments on the larger size requirements for these? Possibly when running in IPC mode? Thank you, Ray From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Wednesday, October 14, 2020 8:52 AM To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, After further analysis, it seems to me that having separate checks for Library mode and IPC mode is the easiest way to go. The current design was done in such a way that both Library and IPC mode can reuse the same crypto service API involving IOVECs. Any change to how the API is invoked from the tfm_crypto_call_sfn() will have ramifications for Library mode. I have done a patch with different checks for IPC and Library mode here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6432 . The patch relaxes the checks for IPC mode to allow empty buffers and hardens the checks for Library mode. Hopefully this should resolve the issue. Best Regards Soby Mathew From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>> Sent: 12 October 2020 17:17 To: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>; 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> Subject: RE: Behavior difference in Crypto IPC vs Library modes Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew 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 Sent: 12 October 2020 11:50 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> Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn’t get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. 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: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I’m seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I’ve been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I’m not sure if the check above is valid for IPC mode. I’ve removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. 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.

5 years

3
2
0 0

Re: [TF-M] Following the TF-M build example

by Raef Coles

Ah okay. This is the behavior we saw with the other VS generators, and why we added the check to make sure "Unix Makefiles" or "Ninja" was used. Because it sets the C compiler to MSVC, it won't correctly compile TFM (which currently only supports ARMClang, GCC, and IAR). While there are other symptoms, such as the issues with python etc, this is the main one. I'd advise to just use -G"Unix Makefiles" (or ninja) Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kevin Kilzer via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 October 2020 18:13 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Following the TF-M build example Hi, Raef, I can get past the CMSIS issue by dup’ing the GNU links. It now fails for lack of the correct Python. Using the -G option, CMakeCache.txt lists all the pythons in my system and the build completes: $ grep python cmake_build/CMakeCache.txt PYTHON_EXECUTABLE:FILEPATH=C:/Python/Python27/python.exe FIND_PACKAGE_MESSAGE_DETAILS_Python3:INTERNAL=[C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe][cfound components: Interpreter ][v3.8.5()] _Python3_EXECUTABLE:INTERNAL=C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe Without the -G option, the compiler is MSVC, and the cache has no entry for python at all. Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) Reason given by package: Interpreter: Wrong major version for the interpreter "C:/Python/Python27/python.exe"

5 years

1
0
0 0

Re: [TF-M] Behavior difference in Crypto IPC vs Library modes

by Soby Mathew

Hi Raymond, As you pointed out, the difference in this case basically boils down to how the 2 models handles empty buffers. In the library mode, the empty buffers are passed down to the target API whereas the IPC mode optimizes the empty buffer from the IOVEC by reducing the buffer length. This results in different error codes in the 2 modes. The sanity check of IOVEC in incoming sizes is needed and I less inclined to remove it or enhance it. The error code certainly seems to be one way to resolve this problem. The other option is to make the IPC mode IOVEC less aggressive in optimizing away zero buffers from IOVEC (Need more investigation) thus attaining parity with library mode. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 12 October 2020 11:50 To: Raymond Ngun <Raymond.Ngun(a)cypress.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi Raymond Thanks for the detailed report. This issue was reported here https://developer.trustedfirmware.org/T822 previously but I didn't get time to look into it further due to other priorities. Your analysis seems right and I will look further into this. 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: 10 October 2020 00:59 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Behavior difference in Crypto IPC vs Library modes Hi all, I'm seeking some assistance in determining the correct fix for a difference in behavior between IPC and Library modes that cause the Crypto PSA Arch Tests to fail when using IPC. Specifically, I've been testing on a PSoC64 for IPC mode and Musca-B1 for Library mode. The problem I am encountering is related to this check in crypto (e.g. crypto_aead.c in secure_fw/partitions/crypto). if ( !((in_len == 2) || (in_len == 3)) || (out_len > 1)) { return PSA_ERROR_CONNECTION_REFUSED; } This is true for direct function call since in_len and out_len are sizes of in_vec[] and out_vec[]. However, in library mode, in_len and out_len is not based on the size of in_vec[] and out_vec[] but based on the contents. Specifically, out_len is determined via the following in tfm_crypto_call_sfn(). /* Check the number of out_vec filled */ while ((out_len > 0) && (msg->out_size[out_len - 1] == 0)) { out_len--; } >From the above, if out_size (which is passed in by the user) is 0, the resultant out_len will be 0. The out_len is passed into the crypto function and PSA_ERROR_CONNECTION_REFUSED is returned due to the check above. PSA, on the other hand, expects PSA_ERROR_NOT_SUPPORTED to be returned. Btw, in_len suffers from the same issue. I'm not sure if the check above is valid for IPC mode. I've removed the check temporarily to avoid the problem. However, if the check still makes sense, possibly it should return PSA_ERROR_NOT_SUPPORTED instead of PSA_ERROR_CONNECTION_REFUSED. Thank you. I look forward to comments. 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

2
2
0 0

Re: [TF-M] TF-M Technical Forum call - October 15

by Anton Komlev

Hello, The agenda for the forum: 1. Interrupt handling in PSA FF-M v1.1 2. Ongoing open issues, discussed on the Forum 3. AOB See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 09 October 2020 11:11 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - October 15 Hello, The next Technical Forum is planned on Thursday, October 15 at 6:00-07:00 UTC (Asia 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

5 years

1
0
0 0

Re: [TF-M] Following the TF-M build example

by Kevin.Kilzer＠microchip.com

Hi, Raef, I can get past the CMSIS issue by dup'ing the GNU links. It now fails for lack of the correct Python. Using the -G option, CMakeCache.txt lists all the pythons in my system and the build completes: $ grep python cmake_build/CMakeCache.txt PYTHON_EXECUTABLE:FILEPATH=C:/Python/Python27/python.exe FIND_PACKAGE_MESSAGE_DETAILS_Python3:INTERNAL=[C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe][cfound components: Interpreter ][v3.8.5()] _Python3_EXECUTABLE:INTERNAL=C:/Users/cXXXXX/AppData/Local/Programs/Python/Python38-32/python.exe Without the -G option, the compiler is MSVC, and the cache has no entry for python at all. Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt Building Custom Rule C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build/lib/ext/mcuboot-subbuild/CMakeLists.txt -- Could NOT find Python3 (missing: Python3_EXECUTABLE Interpreter) Reason given by package: Interpreter: Wrong major version for the interpreter "C:/Python/Python27/python.exe"

5 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M