I want to find a way to clean a memory region in TF-A firmware.

Hi Okash,
Olivier is on holiday and once he is back next week, we can arrange something to discuss.

That is not what I meant. The NS SVE/FP access trap is needed to avoid saving and restoring the state when the SVE/FP registers are actively used by the secure world.

Hi Arve

When you have a S-EL2 based system with possibly multiple S-EL1 partitions, it would be complex to implement a scheme where in EL3 will restore the right S-EL1 context on taking a trap during lazy save mechanism. In such systems, it is easier for S-EL2 to implement such a scheme since it is the manager for S-EL1 contexts.

Hi Yuezhiran,
We are following this up internally. Could you please let us know what revision of Helios you have and whether you run linux? (Linux doesn't work around any Helios errata currently)

Patch fixed and merged

Closed the previous issue https://developer.trustedfirmware.org/T845 as duplicate

Internal ref : https://jira.arm.com/browse/IOTPSW-3471

Cleaning the flash properly seems to solve the issue. Closing this bug as resolved. The SST hardening will taken up as a backlog item.

The latest FVP claims to have resolved this problem. This needs to be re-tested on latest AN521 FVP.

Building the documentation seems to clone all dependancies which seems like an overhead.

A patch is uploaded here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6432

To elaborate the "Support for binary psa-arch-tests (design in progress)​" point mentioned above.

Persistent key support has been added as part of TFMv1.1. Clsoing this issue.

Patches available here https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/4 and https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/4

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.

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

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.

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

Hi Andrew, yes the change looks fine.

ACKed. We need to investigate how to solve this problem.

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.

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.
https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/2263/

HI Rickdic,
Could you please send this query to the TF-A mailing list ?

Hi Sandeep, could you please send a mail to the mailing list for this.

Hi vivina,
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:
https://forums.juniper.net/t5/Security/What-s-the-Difference-between-Secure-Boot-and-Measured-Boot/ba-p/281251

Please email me at soby.mathew@arm.com

Hi Neil
The Cryptocell variant supported by TF-A is CC-712 which only has support for RSA 2048.

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()?

Example comment 3