Hi,
There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces.
I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI functionality is being used here).
So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
Hi, the agenda for the forum tomorrow :
1. News and update by Anton Komlev
2. Open discussion on TF-M documentation structure by David Wang
3. Stateless handle and service in TF-M by Mingyang Sun
4. AOB
Regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M
Sent: Tuesday, March 30, 2021 3:20 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - April 1 (not a joke :)
Hi Anton,
If we still have slot, I'd like to share some thoughts and have a discussion for the TF-M documentation structure. It should be less than 20 mins.
Thanks.
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mingyang Sun via TF-M
Sent: Monday, March 29, 2021 11:15 AM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Technical Forum call - April 1 (not a joke :)
Hi Anton,
I'd like give a short session on "stateless handle and service in TF-M", about 20min.
Regards,
Mingyang
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: Friday, March 26, 2021 6:57 AM
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] Technical Forum call - April 1 (not a joke :)
Hi,
The next Technical Forum is planned on Thursday, April 1 , 07:00-08:00 UTC (Asia time zone).
Please mine the gap of the time change in Europe!
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,
New TF-M Release Candidate 3 is tagged by TF-Mv1.3.0-RC3.
Please update your repositories and report all issues you encountered.
Best regards,
Anton
Hi Everyone,
Let me announce the new maintainers of TF-M project:
* Chris Brand aka UEWBot <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>>
* Ken Liu aka KenLSoft <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
* David Hu aka davidhuziji <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Previous maintainers convinced in your ability to push it forward thanks to your contribution and active involvement to the project development.
At the same time, these maintainers are leaving the club:
* Abhishek Pandit aka abhishek-pandit <abhishek.pandit(a)arm.com<mailto:abhishek.pandit@arm.com>>
* Ashutosh Singh aka ashutoshksingh <ashutosh.singh(a)arm.com<mailto:ashutosh.singh@arm.com>>
* Miklos Balint ara wmnt <miklos.balint(a)arm.com<mailto:miklos.balint@arm.com>>
Huge thanks for your Blood, sweat and tears in bringing TF-M to the way it is now.
Cheers,
Anton
Hi Alexander,
Thanks for your information.
For current TF-Mv1.3.0-RC1, yes, we have some extra failed test cases for crypto psa arch tests. They are 208, 211, 237, 243, and 244. We are now trying to fix them.
206 and 207 are our know issues. Details can be found in our tfm release failure analysis:
https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_f…https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_f…
Thanks,
Summer
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Alexander.Moore--- via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, March 24, 2021 3:55 PM
To: David Hu <David.Hu(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] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25
What’s the build configuration on PSoC 64 with PSA Arch test:
+ BUILD_OPTS='-DTEST_PSA_API=CRYPTO -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2'
+ cmake -S . -B build_clang_psoc64 -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=CRYPTO -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2
-- The C compiler identification is ARMClang 6.12.1
-- The ASM compiler identification is ARMCC
We build both debug/release, and also use gcc/armclang, all four combinations give the same PSA Crypto test results.
What’s the version of TF-M? Have you tried the latest one in master branch:
* We are using the latest master (v1.2.0) and isolated the problem commit to be 28659c498c3bdbbc610959e7518bece5aaf72a19.
What’s the version of PSA Arch test:
* We are using the default tagged version associated with TF-M master branch, which is “8644bd0 musca_s1 support”
Can you share more log of the failure test case:
TEST: 206 | DESCRIPTION: Testing crypto hash functions APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_hash_compute with SHA224 algorithm
[Check 2] Test psa_hash_compute with SHA256 algorithm
[Check 3] Test psa_hash_compute with SHA384 algorithm
[Check 4] Test psa_hash_compute with SHA512 algorithm
[Check 5] Test psa_hash_compute with small buffer size
[Check 6] Test psa_hash_compute with invalid algorithm
Failed at Checkpoint: 3
Actual: -135
Expected: -134
TEST RESULT: FAILED (Error Code=0x1)
TEST: 207 | DESCRIPTION: Testing crypto hash functions APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_hash_compare - SHA224 algorithm
[Check 2] Test psa_hash_compare - SHA256 algorithm
[Check 3] Test psa_hash_compare - SHA384 algorithm
[Check 4] Test psa_hash_compare - SHA512 algorithm
[Check 5] Test psa_hash_compare - incorrect hash
[Check 6] Test psa_hash_compare - incorrect hash length
[Check 7] Test psa_hash_compare - invalid algorithm
Failed at Checkpoint: 3
Actual: -135
Expected: -134
TEST RESULT: FAILED (Error Code=0x1)
TEST: 208 | DESCRIPTION: Testing crypto key derivation APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_key_derivation_setup - ECDH + HKDF-SHA-256
[Check 2] Test psa_key_derivation_setup - ECDH, unknown KDF
[Check 3] Test psa_key_derivation_setup - bad key derivation algorithm
Failed at Checkpoint: 3
Actual: -134
Expected: -135
TEST RESULT: FAILED (Error Code=0x1)
TEST: 211 | DESCRIPTION: Testing crypto hash functions APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_hash_setup with SHA224 algorithm
[Check 2] Test psa_hash_setup with SHA256 algorithm
[Check 3] Test psa_hash_setup with SHA384 algorithm
[Check 4] Test psa_hash_setup with SHA512 algorithm
[Check 5] Test psa_hash_setup with Invalid hash algorithm
Failed at Checkpoint: 3
Actual: -135
Expected: -134
TEST RESULT: FAILED (Error Code=0x1)
TEST: 237 | DESCRIPTION: Testing crypto symmetric cipher APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_cipher_finish - Encrypt - AES CBC_NO_PADDING
[Check 2] Test psa_cipher_finish - Encrypt - AES CBC_NO_PADDING (Short in)
[Check 3] Test psa_cipher_finish - Encrypt - AES CBC_PKCS7
[Check 4] Test psa_cipher_finish - Encrypt - AES CBC_PKCS7 (Short input)
[Check 5] Test psa_cipher_finish - Encrypt - AES CTR
[Check 6] Test psa_cipher_finish - Encrypt - AES CTR (short input)
[Check 7] Test psa_cipher_finish - Encrypt - small output buffer size
[Check 8] Test psa_cipher_finish - Decrypt - AES CBC_NO_PADDING
[Check 9] Test psa_cipher_finish - Decrypt - AES CBC_NO_PADDING (Short in)
Failed at Checkpoint: 8
Actual: -135
Expected: -137
TEST RESULT: FAILED (Error Code=0x1)
TEST: 243 | DESCRIPTION: Testing crypto key derivation APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_raw_key_agreement - ECDH SECP256R1
[Check 2] Test psa_raw_key_agreement - Small buffer size
[Check 3] Test psa_raw_key_agreement - ECDH SECP384R1
[Check 4] Test psa_raw_key_agreement - Invalid usage
[Check 5] Test psa_raw_key_agreement - Unknown KDF
Failed at Checkpoint: 4
Actual: -134
Expected: -135
TEST RESULT: FAILED (Error Code=0x1)
TEST: 244 | DESCRIPTION: Testing crypto key management APIs
[Info] Executing tests from non-secure
[Check 1] Test psa_copy_key - 16 Byte AES
[Check 2] Test psa_copy_key - without copy usage
[Check 3] Test psa_copy_key - invalid lifetime
Failed at Checkpoint: 4
Actual: -136
Expected: -135
TEST RESULT: FAILED (Error Code=0x1)
Thanks,
Alex
From: David Hu <David.Hu(a)arm.com>
Sent: Monday, March 22, 2021 7:56 PM
To: Moore Alexander (CSCA CSS ICW SW PSW 1) <Alexander.Moore(a)infineon.com>
Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>
Subject: RE: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Alexander,
Thanks for reporting this issue.
Can I ask for more details of the failures?
* What’s the build configuration on PSoC 64 with PSA Arch test?
* What’s the version of TF-M? Have you tried the latest one in master branch?
* What’s the version of PSA Arch test?
* Can you share more log of the failure test case?
Thanks.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Alexander.Moore--- via TF-M
Sent: Tuesday, March 23, 2021 6:42 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25
Hello,
After “28659c49 Crypto: Upgrade Mbed TLS to 2.25” we see the following 7 PSA Crypto test failures on PSoC64 which were passing before this commit:
TEST: 206
TEST: 207
TEST: 208
TEST: 211
TEST: 237
TEST: 243
TEST: 244
Are these failures expected? As far as we can tell, there is nothing else to be done associated with the 2.25 upgrade, i.e. the build automatically pulls 2.25 down, and there are no corresponding commits to psa-arch-tests to support the upgrade or any other changes necessary.
Thanks,
Alex
Never mind, I found the issue and have uploaded an updated patch.
/Thomas
Den 2021-03-30 kl. 15:17, skrev Thomas Törnblom via TF-M:
> Hi Anton,
>
> Is it these issues that is causing the problems?
> ---
> In file included from
> ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include\stm32l5xx.h:106:
> ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13:
> warning: parameter 'pointer' not found in the function declaration
> [-Wdocumentation]
> * @param pointer on the vector table containing the reset handler
> the function
> ^~~~~~~
> ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13:
> note: did you mean 'VectorTableAddr'?
> * @param pointer on the vector table containing the reset handler
> the function
> ^~~~~~~
> VectorTableAddr
> ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17:
> warning: parameter 'dP' not found in the function declaration
> [-Wdocumentation]
> * @param[in] dP pΓÇÖs CRT exponent
> ^~
> ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17:
> note: did you mean 'dp'?
> * @param[in] dP pΓÇÖs CRT exponent
> ^~
> dp
> ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17:
> warning: parameter 'dQ' not found in the function declaration
> [-Wdocumentation]
> * @param[in] dQ qΓÇÖs CRT exponent
> ^~
> ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17:
> note: did you mean 'dp'?
> * @param[in] dQ qΓÇÖs CRT exponent
> ^~
> dp
> ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:1185:24:
> warning: unused parameter 'p_rng' [-Wunused-parameter]
> void *p_rng,
> ^
> 4 warnings generated.
> ---
>
> This has nothing to do with my patch but seems related to:
>
> PS
> C:\Users\thomasto\Projects\tf-m8\trusted-firmware-m\platform\ext\target\stm\common\stm32l5xx\accelerator>
> git log rsa_alt.c
> commit 1ea82c0329f45204868df20a3bd8627286c0cdaa
> Author: Michel Jaouen <michel.jaouen(a)st.com>
> Date: Mon Jan 25 15:18:21 2021 +0100
>
> Platform: stm: Add crypto accelerator support
>
> Change-Id: I7c0686c6f6470bebc7f258af125272d28bc4ce84
> Signed-off-by: Michel Jaouen <michel.jaouen(a)st.com>
>
> If it is not that issue, then please elaborate as I get exactly the
> same result with or without my patch when building with armclang.
>
> /Thomas
>
> [
> Den 2021-03-30 kl. 13:27, skrev Anton Komlev via TF-M:
>>
>> Hi Michel, Thomas,
>>
>> The fix
>> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455
>> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>fails
>> for armclang. Please check the CI test.
>>
>> If it’s important feature of the release then could you check and fix
>> it? Let me know if we can progress with RC3 without waiting for the fix.
>>
>> Thanks,
>>
>> Anton
>>
>> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of
>> *Michel JAOUEN via TF-M
>> *Sent:* Monday, March 29, 2021 9:08 PM
>> *To:* tf-m(a)lists.trustedfirmware.org
>> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4
>> failed
>>
>> Thanks , it solved.
>>
>> Best Regards
>>
>> Michel
>>
>> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org
>> <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of
>> *Thomas Törnblom via TF-M
>> *Sent:* lundi 29 mars 2021 17:37
>> *To:* tf-m(a)lists.trustedfirmware.org
>> <mailto:tf-m@lists.trustedfirmware.org>
>> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4
>> failed
>>
>> Apparently I have not tested this before.
>>
>> Check the fix at:
>> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455
>> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>
>>
>> /Thomas
>>
>> Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M:
>>
>> Sure
>>
>> Variable $tfm_work point to trustedfirmware local dir.
>>
>> Here is my command
>>
>> cmake -S . -B build_dir -G"Unix Makefiles"
>>
>> -DTFM_PLATFORM=stm/stm32l562e_dk
>>
>> -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake
>>
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>>
>> -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2
>>
>> Best regards
>>
>> Michel
>>
>> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org
>> <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of
>> *Thomas Törnblom via TF-M
>> *Sent:* lundi 29 mars 2021 16:06
>> *To:* tf-m(a)lists.trustedfirmware.org
>> <mailto:tf-m@lists.trustedfirmware.org>
>> *Subject:* Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4
>> failed
>>
>> Hi Michel,
>>
>> Can you provide the cmake line and I'll have a look.
>>
>> That argument looks like a gcc argument not recognized by the IAR
>> tools.
>>
>> Cheers,
>> Thomas
>>
>> Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M:
>>
>> Hello,
>>
>> I got the following build issue when I build with IARAR, it
>> occurs when build mbed-crypto
>>
>> IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM
>>
>> Copyright 1999-2020 IAR Systems AB.
>>
>> Network license: 10.157.2.156 (STD)
>>
>> Command line error: Unexpected command line arguments:
>>
>> -Wno-unused-parameter
>>
>> Does someone else reproduce the issue ?
>>
>> Best regards
>>
>> --
>>
>> *Thomas Törnblom*, /Product Engineer/
>> IAR Systems AB
>> Box 23051, Strandbodgatan 1
>> SE-750 23 Uppsala, SWEDEN
>> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
>> E-mail: thomas.tornblom(a)iar.com
>> <mailto:thomas.tornblom@iar.com>Website: www.iar.com
>> <http://www.iar.com>
>> Twitter: www.twitter.com/iarsystems
>> <http://www.twitter.com/iarsystems>
>>
>> --
>>
>> *Thomas Törnblom*, /Product Engineer/
>> IAR Systems AB
>> Box 23051, Strandbodgatan 1
>> SE-750 23 Uppsala, SWEDEN
>> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
>> E-mail: thomas.tornblom(a)iar.com
>> <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com>
>> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>>
>>
>
> --
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
> Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Anton,
Is it these issues that is causing the problems?
---
In file included from
..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include\stm32l5xx.h:106:
..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13:
warning: parameter 'pointer' not found in the function declaration
[-Wdocumentation]
* @param pointer on the vector table containing the reset handler
the function
^~~~~~~
..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13:
note: did you mean 'VectorTableAddr'?
* @param pointer on the vector table containing the reset handler
the function
^~~~~~~
VectorTableAddr
..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17:
warning: parameter 'dP' not found in the function declaration
[-Wdocumentation]
* @param[in] dP pΓÇÖs CRT exponent
^~
..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17:
note: did you mean 'dp'?
* @param[in] dP pΓÇÖs CRT exponent
^~
dp
..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17:
warning: parameter 'dQ' not found in the function declaration
[-Wdocumentation]
* @param[in] dQ qΓÇÖs CRT exponent
^~
..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17:
note: did you mean 'dp'?
* @param[in] dQ qΓÇÖs CRT exponent
^~
dp
..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:1185:24:
warning: unused parameter 'p_rng' [-Wunused-parameter]
void *p_rng,
^
4 warnings generated.
---
This has nothing to do with my patch but seems related to:
PS
C:\Users\thomasto\Projects\tf-m8\trusted-firmware-m\platform\ext\target\stm\common\stm32l5xx\accelerator>
git log rsa_alt.c
commit 1ea82c0329f45204868df20a3bd8627286c0cdaa
Author: Michel Jaouen <michel.jaouen(a)st.com>
Date: Mon Jan 25 15:18:21 2021 +0100
Platform: stm: Add crypto accelerator support
Change-Id: I7c0686c6f6470bebc7f258af125272d28bc4ce84
Signed-off-by: Michel Jaouen <michel.jaouen(a)st.com>
If it is not that issue, then please elaborate as I get exactly the same
result with or without my patch when building with armclang.
/Thomas
[
Den 2021-03-30 kl. 13:27, skrev Anton Komlev via TF-M:
>
> Hi Michel, Thomas,
>
> The fix
> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455
> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>fails
> for armclang. Please check the CI test.
>
> If it’s important feature of the release then could you check and fix
> it? Let me know if we can progress with RC3 without waiting for the fix.
>
> Thanks,
>
> Anton
>
> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of
> *Michel JAOUEN via TF-M
> *Sent:* Monday, March 29, 2021 9:08 PM
> *To:* tf-m(a)lists.trustedfirmware.org
> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
>
> Thanks , it solved.
>
> Best Regards
>
> Michel
>
> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org
> <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of *Thomas
> Törnblom via TF-M
> *Sent:* lundi 29 mars 2021 17:37
> *To:* tf-m(a)lists.trustedfirmware.org
> <mailto:tf-m@lists.trustedfirmware.org>
> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
>
> Apparently I have not tested this before.
>
> Check the fix at:
> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455
> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>
>
> /Thomas
>
> Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M:
>
> Sure
>
> Variable $tfm_work point to trustedfirmware local dir.
>
> Here is my command
>
> cmake -S . -B build_dir -G"Unix Makefiles"
>
> -DTFM_PLATFORM=stm/stm32l562e_dk
>
> -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake
>
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>
> -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2
>
> Best regards
>
> Michel
>
> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org
> <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of
> *Thomas Törnblom via TF-M
> *Sent:* lundi 29 mars 2021 16:06
> *To:* tf-m(a)lists.trustedfirmware.org
> <mailto:tf-m@lists.trustedfirmware.org>
> *Subject:* Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
>
> Hi Michel,
>
> Can you provide the cmake line and I'll have a look.
>
> That argument looks like a gcc argument not recognized by the IAR
> tools.
>
> Cheers,
> Thomas
>
> Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M:
>
> Hello,
>
> I got the following build issue when I build with IARAR, it
> occurs when build mbed-crypto
>
> IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM
>
> Copyright 1999-2020 IAR Systems AB.
>
> Network license: 10.157.2.156 (STD)
>
> Command line error: Unexpected command line arguments:
>
> -Wno-unused-parameter
>
> Does someone else reproduce the issue ?
>
> Best regards
>
> --
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com
> <mailto:thomas.tornblom@iar.com>Website: www.iar.com
> <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems
> <http://www.twitter.com/iarsystems>
>
> --
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com
> <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
>
>
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Michel, Thomas,
The fix https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 fails for armclang. Please check the CI test.
If it's important feature of the release then could you check and fix it? Let me know if we can progress with RC3 without waiting for the fix.
Thanks,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M
Sent: Monday, March 29, 2021 9:08 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
Thanks , it solved.
Best Regards
Michel
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M
Sent: lundi 29 mars 2021 17:37
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
Apparently I have not tested this before.
Check the fix at:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455
/Thomas
Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M:
Sure
Variable $tfm_work point to trustedfirmware local dir.
Here is my command
cmake -S . -B build_dir -G"Unix Makefiles"
-DTFM_PLATFORM=stm/stm32l562e_dk
-DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2
Best regards
Michel
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M
Sent: lundi 29 mars 2021 16:06
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed
Hi Michel,
Can you provide the cmake line and I'll have a look.
That argument looks like a gcc argument not recognized by the IAR tools.
Cheers,
Thomas
Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M:
Hello,
I got the following build issue when I build with IARAR, it occurs when build mbed-crypto
IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM
Copyright 1999-2020 IAR Systems AB.
Network license: 10.157.2.156 (STD)
Command line error: Unexpected command line arguments:
-Wno-unused-parameter
Does someone else reproduce the issue ?
Best regards
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
--
Thomas Törnblom, Product Engineer
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>
Hi Anton,
If we still have slot, I'd like to share some thoughts and have a discussion for the TF-M documentation structure. It should be less than 20 mins.
Thanks.
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mingyang Sun via TF-M
Sent: Monday, March 29, 2021 11:15 AM
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - April 1 (not a joke :)
Hi Anton,
I'd like give a short session on "stateless handle and service in TF-M", about 20min.
Regards,
Mingyang
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: Friday, March 26, 2021 6:57 AM
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] Technical Forum call - April 1 (not a joke :)
Hi,
The next Technical Forum is planned on Thursday, April 1 , 07:00-08:00 UTC (Asia time zone).
Please mine the gap of the time change in Europe!
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 Jamie,
Could help to provide the details so that we can see what the problem is? Looks like you mentioned two problems here, one for the un-aligned memory accessing and another is the FLASH read/write.
For the memory alignment, to ensure the isolation setting all sections should be 32-bytes aligned; and the stack-alignment is 8 bytes. Other contents are set as default, the toolchain should have handled them correctly.
Please provide the details, thank you!
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Monday, March 29, 2021 10:19 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] Issues with alignment and buffer locations
Hi,
There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces.
I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI functionality is being used here).
So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this?
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
