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
