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.
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.
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.
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.
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, 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
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.
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.
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.
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"
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.
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
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"
Hi, Raef,
The combination that worked was the most-recent commit and gnu tools (-G option). Using VS it fails at lib/ext/CMSIS_5/CMakeLists.txt:25 for lack of CMSIS RTX static libraries.
...this command worked....
$ cmake -S . -B cmake_build -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -G"Unix Makefiles"
-- The C compiler identification is GNU 9.3.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/9 2020-q2-update/bin/arm-none-eabi-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
Thanks. I'm interested if you've managed to build TFM using the visual studio generator? That check was actually added because we had a problem with at least one of the visual studio generators (VS10) setting the C compiler to `MSVC`. If you've managed to get it to build with VS16, then we can look in to adding that as a known good generator.
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: 13 October 2020 15:30
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Following the TF-M build example
Hi, Raef,
I added to the generator qualifier in CMakeLists.txt line 17. Since cmake is not my native language, I put in the full string, as you see. The string comes from the display of CMAKE_GENERATOR in the error message.
if(NOT ${CMAKE_GENERATOR} STREQUAL "Unix Makefiles" AND
NOT ${CMAKE_GENERATOR} STREQUAL "Visual Studio 16 2019" AND
NOT ${CMAKE_GENERATOR} STREQUAL "Ninja")
Message(FATAL_ERROR "Unsupported generator ${CMAKE_GENERATOR}. Hint: Try -G\"Unix Makefiles\"")
endif()
Hi, Raef,
I added to the generator qualifier in CMakeLists.txt line 17. Since cmake is not my native language, I put in the full string, as you see. The string comes from the display of CMAKE_GENERATOR in the error message.
if(NOT ${CMAKE_GENERATOR} STREQUAL "Unix Makefiles" AND
NOT ${CMAKE_GENERATOR} STREQUAL "Visual Studio 16 2019" AND
NOT ${CMAKE_GENERATOR} STREQUAL "Ninja")
Message(FATAL_ERROR "Unsupported generator ${CMAKE_GENERATOR}. Hint: Try -G\"Unix Makefiles\"")
endif()
Note that the aforementioned patch has now been merged - windows build should now be working again on master
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 13 October 2020 10:24
To: tf-m(a)lists.trustedfirmware.org; Kevin.Kilzer(a)microchip.com
Subject: Re: [TF-M] Following the TF-M build example
Hi,
I'm interested in the changes that you made to the validity checks, would you mind sending a patch / outlining what you had to change. The windows generator checks are still not working exactly as they should and I'd like to know what your experience was.
For the build failure, I believe this might be related to an issue with the windows PSA file generation. We've got a patch in review for this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6386, can you test and see if that fixes the problem.
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: 13 October 2020 00:20
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Following the TF-M build example
Thanks for the notes. Since last week I’ve now:
1. downloaded today’s latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and
2. added the VS compiler to the “valid” checks at CmakeLists.txt line 17.
Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD).
Thanks for any help.
==========
-- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build
cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master)
$ cmake --build cmake_build -- install
tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed
make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
make.exe: *** [all] Error 2==========
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
I'm interested in the changes that you made to the validity checks, would you mind sending a patch / outlining what you had to change. The windows generator checks are still not working exactly as they should and I'd like to know what your experience was.
For the build failure, I believe this might be related to an issue with the windows PSA file generation. We've got a patch in review for this at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6386, can you test and see if that fixes the problem.
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: 13 October 2020 00:20
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Following the TF-M build example
Thanks for the notes. Since last week I’ve now:
1. downloaded today’s latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and
2. added the VS compiler to the “valid” checks at CmakeLists.txt line 17.
Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD).
Thanks for any help.
==========
-- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build
cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master)
$ cmake --build cmake_build -- install
tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed
make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
make.exe: *** [all] Error 2==========
Hi,
While digging the clean issue brought up by Soby, I started wondering if external dependency handling would be better in a slightly different way. There is a lot of hack in the build system around including the psa-arch test project, mostly to work around cmake limitations on namespaces and symbol separation. A stronger barrier could eliminate the mess. In TS we use the following pattern (let's call it "Internal Project"):
* External dependencies are fetched with fetch_content()
* Right after the fetch, execute_process() is called to start the build of the component. So external component builds configuration time.
* The project get's installed into a directory and the main project is using the installed content, possibly through find_package().
* Benefits:
* This gives a stronger separation, elimination any name clash between the main project and the external dependency. Also global settings cannot collide like when a dependency sets CMAKE_BUILD_TYPE.
* Faster main project build times, as external projects are only built once.
* Makes it more "natural" to use an externally built binary for an external component. This might be handy from QA perspective if binary releases are going to happen. (If ever of course.)
* Strong separation could allow using different version of the same tools for components. (i.e. main project is built with GCC, component with IAR.)
* Drawbacks:
* It is harder to develop the external component together with tf-m s tracking changes is more difficult. Might be a problem if debugging tf-m vs external component interaction. This should be rare and might be an acceptable issue.
* It is unnatural to run builds configuration time in cmake world.
* Configuration phase will take longer.
* Since the build happens right where the external component is added (point A), cmake execution flow might need to be different to ensure all information needed to configure the external component is present at point A.
* Since external component is built by a separated cmake run, tool detection happens separate. This means the same tools will be searched for multiple times. Initial cache files can be a workaround.
This is very similar to how external projects work in cmake, but makes better integration possible. The main project can use information from the dependency as it's source and output files become available configuration time. In turn external project changes are harder to track.
/George
Hi,
I tried to dig deeper into this, but the cmake command used by Soby fails for me.
"
[ 33%] Performing patch step for 'psa_arch_tests-populate'
error: patch failed: api-tests/platform/targets/tgt_dev_apis_tfm_an521/nspe/pal_driver_intf.c:128
...
"
It would be nice to understand why cmake fails to clean properly, but well, I cannot deep-dive due to the above. What I wanted to check is if https://cmake.org/cmake/help/v3.15/prop_tgt/ADDITIONAL_CLEAN_FILES.html could be used to get "make clean" remove the psa-arch test binary directory. But:
* I am not sure which build directory is used. I have the feeling we use ${CMAKE_CURRENT_BINARY_DIR}/psa_api_tests and not psa_arch_tests_BINARY_DIR, which would be build\lib\ext\psa_arch_tests-build. Strange.
* ADDITIONAL_CLEAN_FILES was introduced in cmake v3.15 and if my memories are correct tf-m allows an older version if not using IAR.
Soby: can you please test if ADDITIONAL_CLEAN_FILES works? This solution would give a more streamlined.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: 12 October 2020 23:00
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] New TF-M Build doesn't track config changes
Hi,
Thanks Soby for sorting it out.
Sounds like a right way to go and cleanall shall do that job.
For me it looks like an exceptional case while the main scenario for a daily development shall be the one, described by Karl : downloaded dependencies explicitly specified by paths outside of TF-M tree via command line, or via project config file (suggested).
And true, both cases shall be explicitly documented.
Hope it helps,
Anton
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 17:29
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] New TF-M Build doesn't track config changes
Thanks Karl, Gyorgy for your inputs.
I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info).
Does that sound like a good plan then ?
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M
Sent: 12 October 2020 06:29
To: 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] New TF-M Build doesn't track config changes
Hi,
I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too.
So the correct operation (in my opinion) is to make the dependency download work in the following way:
* If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...)
* If not cmake shall do the fetch.
This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean.
As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M
Sent: 10 October 2020 08:14
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] New TF-M Build doesn't track config changes
Hi Soby,
I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit.
The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario.
-DMBEDCRYPTO_PATH=
-DTFM_TEST_REPO_PATH=
-DMCUBOOT_PATH=
-DPSA_ARCH_TESTS_PATH=
There is an example from CI for build command:
https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu…
cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m
BR
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Friday, October 2, 2020 8:40 PM
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>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] New TF-M Build doesn't track config changes
Hi,
With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either.
The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below:
/* Build secure regressions test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install
/* reconfigure and build PSA Crypto API test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install
Built binary is still for regression test suite.
There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this.
Best Regards
Soby Mathew
Thanks for the notes. Since last week I've now:
1. downloaded today's latest repo (12 October, commit 8bebd05745a8b27dccc6403f0215fa6e39de3bc1, and
2. added the VS compiler to the "valid" checks at CmakeLists.txt line 17.
Using the -G option allows the make to complete (apparently), but the install script fails (in both GitBash and CMD).
Thanks for any help.
==========
-- Build files have been written to: C:/Users/cXXXXX/Git/arm/TF-M/trusted-firmware-m/cmake_build
cXXXXX@LT-cXXXXXA MINGW64 ~/Git/arm/TF-M/trusted-firmware-m (master)
$ cmake --build cmake_build -- install
tools/CMakeFiles/tfm_generated_files.dir/build.make:93: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:944: recipe for target 'tools/CMakeFiles/tfm_generated_files.dir/all' failed
make.exe[1]: *** [tools/CMakeFiles/tfm_generated_files.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
make.exe: *** [all] Error 2==========
Hi,
Thanks Soby for sorting it out.
Sounds like a right way to go and cleanall shall do that job.
For me it looks like an exceptional case while the main scenario for a daily development shall be the one, described by Karl : downloaded dependencies explicitly specified by paths outside of TF-M tree via command line, or via project config file (suggested).
And true, both cases shall be explicitly documented.
Hope it helps,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M
Sent: 12 October 2020 17:29
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] New TF-M Build doesn't track config changes
Thanks Karl, Gyorgy for your inputs.
I agree with the principle that `BUILD` shall be only folder the cmake modifies. The trouble is, after a `make clean`, there are still artefacts from the previous configuration which affects the new build and gives the wrong output. Hence the suggestion to introduce a `cleanall` custom target which endeavours to clean the all the remnant config information from previous build and leave auto cloned dependant repositories untouched (or maybe print some status info).
Does that sound like a good plan then ?
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M
Sent: 12 October 2020 06:29
To: 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] New TF-M Build doesn't track config changes
Hi,
I think the build directory is owned by cmake and the same rules shall apply to all files there. Also the only directory cmake does modify without the users consent shall be the build directory. As long as cmake is owning the external dependencies it is the responsibility of the build system to keep the dependencies in a healthy state and to ensure the correct version is built. To do this safely the "clean" operation, which is used to get out of a "non-operational" state, shall fix the dependencies too.
So the correct operation (in my opinion) is to make the dependency download work in the following way:
* If the dependency is already present at the target location, cmake shall use it as is. Possibly some status information should be printed (i.e. version number, if the git working copy is dirty etc...)
* If not cmake shall do the fetch.
This way if the user specify an external location (one not in the build directory), cmake will "export" the dependency when the first fetch is done, and do no modifications after. This gives us a well-defined act of handing over the responsibility of keeping the dependency clean.
As far as I can see (was not digging into the details) this more or less matches how the current implementation works, and what is missing is more details in the documentation.
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Karl Zhang via TF-M
Sent: 10 October 2020 08:14
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] New TF-M Build doesn't track config changes
Hi Soby,
I met the same problem before, and I think your suggestions are helpful. There might be more check needed if the 'make clean' does not delete the auto cloned repos. Because the dependencies may update by a new TFM commit.
The new build system supports to specify the patch of each dependency, which can avoid clone automatically to the build folder each time. Hope it can mitigate the inconvenient scenario.
-DMBEDCRYPTO_PATH=
-DTFM_TEST_REPO_PATH=
-DMCUBOOT_PATH=
-DPSA_ARCH_TESTS_PATH=
There is an example from CI for build command:
https://ci.trustedfirmware.org/view/TF-M/job/tf-m-build-config/lastStableBu…
cmake -DTFM_PLATFORM=mps2/an519 -DCMAKE_TOOLCHAIN_FILE=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/toolchain_GNUARM.cmake -DTFM_PSA_API=True -DTFM_ISOLATION_LEVEL=1 -DTEST_NS=False -DTEST_S=False -DTEST_PSA_API=OFF -DCMAKE_BUILD_TYPE=Debug -DCRYPTO_HW_ACCELERATOR_OTP_STATE=False -DBL2=False -DNS=False -DTFM_TEST_REPO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../tf-m-tests -DMBEDCRYPTO_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mbedtls -DPSA_ARCH_TESTS_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../psa-arch-tests -DMCUBOOT_PATH=/home/buildslave/workspace/tf-m-build-config/trusted-firmware-m/../mcuboot -DTFM_PROFILE= /home/buildslave/workspace/tf-m-build-config/trusted-firmware-m
BR
Karl
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Soby Mathew via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: Friday, October 2, 2020 8:40 PM
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>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: [TF-M] New TF-M Build doesn't track config changes
Hi,
With the new build system, TF-M downloads all dependant repositories to the BUILD folder as part of CMAKE configuration. CMake does provide `make clean` target to clean the build and rebuild but this doesn't track any config changes between the builds. Previously, the CMake workflow was to delete all contents in the BUILD folder before re-configuring for a new build but now this means the developer has to re-download all the dependant git repositories before the project can be build again. This can be a slow and cumbersome process for developers. Deleting the CMakecache.txt doesn't seem to solve the problem either.
The most obvious solution is to move the cloned repositories outside the BUILD/ folder , so we can follow the previous workflow of deleting the BUILD folder before re-build. The sample test sequence to reproduce the problem is given below:
/* Build secure regressions test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug; make install
/* reconfigure and build PSA Crypto API test suite */
$ make clean; cmake .. -DTFM_PLATFORM=mps2/an521 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_PSA_API=CRYPTO; make install
Built binary is still for regression test suite.
There are multiple suggestions to solve the problem, One is to move the clone repositories outside the BUILD/ folder, or introduce a build target like `make cleanall` which does the equivalent of rm -rf !(lib) within the BUILD folder (i.e the build target will remove all folders except the lib folder which has the cloned repositories). Please let us know of your suggestions on this.
Best Regards
Soby Mathew
