Apply patches from TF-M v2.3#8
Open
valeriosetti wants to merge 17 commits into
Open
Conversation
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
from
841e62c to
1225160
Compare
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
from
b360c97 to
36493e9
Compare
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
2 times, most recently
from
8c76e74 to
f98800d
Compare
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
2 times, most recently
from
2d0236b to
d82da88
Compare
|
It seems that I am not a contributor to this repo yet so I cannot add a review. But I checked the commits here and the diff is the same as the patch files in the TF-M repo: The following commit: is now merged upstream so you can updated the title to include [tfm]. The last revert that does not exist in upstream TF-M yet makes to me. So overall this looks good, if I get the rights I can leave a review. |
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
from
d82da88 to
b6bb991
Compare
Collaborator
Author
|
@Vge0rge thanks for your review!
Updated TF-M commit patch with what's currently in TF-M's
Yes, but there is a PR for it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/50789 |
…a_crypto_config.c This is required because if the user defined configuration file (not the default one provided by tf-psa-crypto) includes files from the standard C library then __STDC_WANT_LIB_EXT1__ won't be defined there which cause weird build failures. Signed-off-by: Valerio Setti <vsetti@baylibre.com> Upstream PR #: 777
TF-M requires a mechanism to leverage the drivers and builtin keys at the same time to allow for "transparent builtin keys". More details are in the TF-M design doc. Provide directly the wrappers instead of modifying the autogen scripts, for the time being. Signed-off-by: Raef Coles <raef.coles@arm.com> Co-authored-by: Antonio de Angelis <antonio.deangelis@arm.com>
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
…to_init() This patch amends the order of initialisations performed in psa_crypto_init() to make sure that the driver wrappers based on the PSA driver API are initialised just after the key slots in memory, both of them at the beginning of the initialisation sequence. Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Manually hardcode PSA driver entry points for the CC3XX driver into psa crypto driver wrappers file (and provide missing entry point definitions if any). This is a temporary solution until the codegen framework is available for automatic integration. Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com> Co-authored-by: Amjad Ouled-Ameur <amjad-ouled-ameur@arm.com>
Add an option to let the compiler generate the assembly code for u32_muladd64(), especially for MinSizeRel and Release builds. Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
…n block size In case key_length is equal to block_size, memset would be called with a destination address outside the boundary of ipad and opad, with a null size. Since memset implementation is compiler-dependent, it is a good practice not to assume that it won't dereference the out-of-bound destination address. Instead, only call memset if key_length is less than block_size. Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
TF-M requires a mechanism to leverage the use of HW-managed keys, the concept is called "Opaque Keys". Basically, the key ID as well as the key buffer are interpreted differently by the crypto accelerator driver. Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com> Signed-off-by: Waleed Elmelegy <waleed.elmelegy@arm.com> Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com> Signed-off-by: Maulik Patel <maulik.patel@arm.com>
This adds support for CMAC-based, counter mode key-derivation function, using the construction recommended by NIST Special Publication 800-108r1 [0]. [0]: https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final Change-Id: Ica1d48ebc62c5d2c98507b6908fe73b4194c95a1 Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
Add experimental support for PSA_ALG_LMS to PSA as a vendor algorithm and extend the PSA_ALG_IS_VENDOR_HASH_AND_SIGN macro accordingly. Signed-off-by: David Vincze <david.vincze@arm.com>
Do not include context definitions or additional symbols used by built-in crypto modules/drivers for a PSA Crypto client. These are not needed when a client is built with the MBEDTLS_PSA_CRYPTO_CLIENT configuration option enabled, and excluding them prevents unnecessary build errors due to missing private dependencies. Signed-off-by: David Vincze <david.vincze@arm.com>
Its prototype was removed from the public interface by 327c9c0. TF-M keeps using this function - add again to avoid build errors. Signed-off-by: David Vincze <david.vincze@arm.com>
…SA Crypto Core This adds support for CMAC-based, counter mode key-derivation function, using the construction recommended by NIST Special Publication 800-108r1 [0]. [0]: https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
This allows passing cc3xx opaque keys to the PSA Core seamlessly via the existing TF-M builtin key platform hooks. Signed-off-by: Amjad Ouled-Ameur <amjad.ouled-ameur@arm.com>
AES keywrap support was previously added for TF-M (commit dc5843f252) but was unintentionally removed when the PSA interface headers were aligned to TF-PSA-Crypto 1.0.0 (commit 9f2d6c6) since these changes were not included in any .patch files. Change-Id: I09dd45f93b3e42f8afa51c87014e6e73c3532499 Signed-off-by: Waleed Elmelegy <waleed.elmelegy@arm.com> Signed-off-by: David Vincze <david.vincze@arm.com>
Do not try to include bounds-checking functions from this standard library extension when building with the ATfE toolchain. Defining __STDC_WANT_LIB_EXT1__ led to build errors due to inconsistency in the toolchain configuration. Change-Id: I350e6d037119b2ece0e42f55d65a7dc2eaa83b5a Signed-off-by: Anton Komlev <anton.komlev@arm.com> Signed-off-by: David Vincze <david.vincze@arm.com>
…client" This creates issues with the Zephyr NS build. The reason is that the reverted commit would exclude some include files when MBEDTLS_PSA_CRYPTO_C is not defined (as it happens when building NS), but these are still required to build Mbed TLS because the TLS part still refers to some TF-PSA-Crypto internal types (ex: mbedtls_ecp_group_id). The TF-M PR that's trying to upstream this change has change-id: Ib3dd8a40bff2587d1703219cd303630ce06addac. This commit it still marked as '[zep noup]' because it seems that this TF-M's PR is experiencing opposition from reviewers and it might be the case that's never accepted.
valeriosetti
force-pushed
the
tfm-bump-2.3
branch
from
b6bb991 to
b3c5348
Compare
Collaborator
Author
|
This is now ready for review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These patches are taken from TF-M v2.3 at path
modules/tee/tf-m/trusted-firmware-m/lib/ext/tf-psa-crypto/.Commits are labeled as
[zep tfm-patch]in order to differentiate them from other[zep noup]we apply in this repo. This must be discussed with @tomi-font and @ceolin though because it's not documented anywhere.