- User Since
- Sep 28 2018, 3:39 PM (103 w, 1 d)
Aug 17 2020
Apr 21 2020
One comment regarding fully supported platform :"It builds all supported configurations." , There may be configuration in the project which are isolated to some niche use-cases or niche market segment and may not be applicable to the platform and intended target market.
Mar 30 2020
Internal ref: https://jira.arm.com/browse/IOTPSW-2914
Internal ref : https://jira.arm.com/browse/IOTPSW-2861
Internal ref : https://jira.arm.com/browse/IOTPSW-2826
Internal ref: https://jira.arm.com/browse/IOTPSW-2801
Internal ref: https://jira.arm.com/browse/IOTPSW-2817
Mar 26 2020
This causes random failure in PSA Arch ITS and PSA Arch PS tests.
See related Musca-A2 issue here : https://developer.trustedfirmware.org/T694
We would need to support versioning of SST FS data and also have mechanisms to detect if the flash is clean or in consistent state.
Internal ref : https://jira.arm.com/browse/IOTPSW-2808
This issue is also seen on Musca-A board.
Mar 25 2020
This is an issue on FVP. It will case the system cannot boot up after a warm reset. So as a workaround, we have to skip BL2 when testing.
The output hangs at this point :
Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. [INF] Starting bootloader [INF] Image 0: version=0.0.0+5, magic= good, image_ok=0x3 [INF] Image 1: No valid image [INF] Booting image from the primary slot [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! TFM level is: 0x00000001 [Sec Thread] Jumping to non-secure code...
This is a known limitation of CC-312 and hence will not be fixed in TF-M code.
Update from Tamas
Mar 12 2020
Hi Andrew, yes the change looks fine.
Mar 3 2020
ACKed. We need to investigate how to solve this problem.
Feb 25 2020
Yes, the mbed-crypto tag 3.1.0 adds these 2 new APIs whereas the version TF-M currently supports is 3.0.1. I intend to catch up once again in a month's time and hopefully by then mbed-crypto will have added more functions which can be utilized.
Jan 14 2020
Closing the issue as the RSA Key size support has now been merged.
The TF-A now has support for RSA-3K in Cryptocell variant.
Jan 7 2020
Could you please send this query to the TF-A mailing list ?
Dec 2 2019
Hi Sandeep, could you please send a mail to the mailing list for this.
Nov 26 2019
At the face of it, there is an issue. Could I ask you to post this on the mailing list as I think this discussion may be of interest to wider community ?
Oct 21 2019
Sep 5 2019
Are you thinking something similar to measured boot ?
The TF-A implements what is called verified boot. Found a good description for difference between verified and measured boot here:
Jul 10 2019
Please email me at firstname.lastname@example.org
The Cryptocell variant supported by TF-A is CC-712 which only has support for RSA 2048.
Jun 10 2019
May 28 2019
May 21 2019
Ah, You are right. Having taken a look at it again, yes, the SP-> SPM communication is register based and this spm_response_add() is invoked by SPM to push to a buffer within EL3 (its not a shared buffer between different ELs). I suspect the shared buffer primitives were written with shared buffer scenario in mind and the current prototype implementation does not optimize it for the case when the buffer is within EL3.
Who is the lockless reader for spm_response_add() and spm_response_get()?
May 8 2019
Example comment 3