saves ~2KB of code size and can be disabled at build time.

RFC7539 tests for verification as part of the TF-M regression test suite: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/14551

Poly1305 multipart support in the low level driver: https://review.trustedfirmware.org/q/topic:%22poly1305_multipart%22+(status:open%20OR%20status:merged)

Working in progress on this. Current low level APIs are not very well versed to be adapted efficiently for multipart cases. I am studying the algorithms first before defining a strategy to implement the multipart APIs and eventually (maybe) rework the low level driver API as well

To be added to arm-cortex-m.cfg:

manually cut compile_commands.json only for interface files:

FYI: @noonfom @Anton-TF

https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12379

Tests: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11880
GCM driver: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12275

Original refactoring patch (merged first, could not add the topic tag anymore): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12221

mbedTLS PR has now been merged on development branch. Started work focusing on GCM.

Add the remaining case for 8-byte IVs during refactoring work, and when tests are available.

Note: Feedback to the PSA spec team for a priority value to be associated to each JSON file for those configurations where we have multiple accelerators available.

The spec currently defines an attribute for an entry point (or family of) in the JSON file, i.e. algorithms, which is used by the core to decide if the entry point needs to be applied for a particular algorithm or not. The JSON file is meant to be consumed as a description of the driver by the mbedTLS parser at build time, in order to link the driver entry points properly into the driver core.

After additional analysis, the summary of the discussion is that these entry points are more suited to be implemented for an hardware which implements a fast way to provide random numbers. CC-312 exposes a TRNG source through the get_entropy entry point, but the remaining part of the DRBG algorithms is implemented in firmware (possibly only partially accelerating parts of them through the driver crypto core transparently calling into the driver from within its own software implementation). For this reason, I am marking this item as Won't do.

Verified by building qemu 6.1.0 from source as it's been released on 24/08. Regression for AN521 passes without problem on this version. Closing this ticket with a recommendation to re-enable Open CI test cases based on Qemu after upgrading the Qemu version available in Open CI to 6.1.0.