static function mbedtls_set_key_owner() is declared in psa/crypto.h
and defined in psa/crypto_struct.h with different parameter name for
the mbedtls_key_owner_id_t parameter and that may trigger errors
from static code analysis tool as cppcheck.
Signed-off-by: Antonio de Angelis <antonio.deangelis@arm.com>
Use PSA_BUILTIN macros instead of the Mbed TLS ones
as in the hash operation contexts the context for a
given hash is needed only if the support for it
through PSA is enabled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This commit removes the test_psa_crypto_config_basic
all.sh component that can no longer work without
adapting it to the separately compiled test driver
library. This component is replaced by several
components in the following commits to test various
type of acceleration independently.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The PSA max hash size has to be 64 if SHA512 or
SHA384 is supported by the library or an
accelerator, not just in case of the library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Several files among include/psa/crypto_*.h are not meant to be included
directly, and are not guaranteed to be valid if included directly. This
makes it harder to perform some static analyses. So make these files more
self-contained so that at least, if included on their own, there is no
missing macro or type definition (excluding the deliberate use of forward
declarations of structs and unions).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
- Add return value description to the docs of mbedtls_sha256
- Remove description of non-existing "mode" parameter from the docs of mbedtls_aes_crypt_ctr
Backport of #5105
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
This slightly increases the RAM consumption per context, but saves code
size on architectures with an instruction for direct byte access (which is
most of them).
Although this is technically an API break, in practice, a realistic
application won't break: it would have had to bypass API functions and rely
on the field size (e.g. relying on -1 == 1 in a 1-bit field).
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/ssl_cli.o: 19952 -> 19900 (diff: 52)
library/ssl_msg.o: 25810 -> 25798 (diff: 12)
library/ssl_srv.o: 22371 -> 22299 (diff: 72)
library/ssl_tls.o: 23274 -> 23038 (diff: 236)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 2868 -> 2848 (diff: 20)
library/ssl_msg.o: 2916 -> 2924 (diff: -8)
library/ssl_srv.o: 3204 -> 3184 (diff: 20)
library/ssl_tls.o: 5860 -> 5756 (diff: 104)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move small fields first so that more fields can be within the Arm Thumb
128-element direct access window.
The ordering in this commit is not based on field access frequency.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/ssl_cli.o: 20104 -> 19952 (diff: 152)
library/ssl_msg.o: 25942 -> 25810 (diff: 132)
library/ssl_srv.o: 22467 -> 22371 (diff: 96)
library/ssl_tls.o: 23390 -> 23274 (diff: 116)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 2928 -> 2868 (diff: 60)
library/ssl_msg.o: 2924 -> 2916 (diff: 8)
library/ssl_srv.o: 3232 -> 3204 (diff: 28)
library/ssl_tls.o: 5904 -> 5860 (diff: 44)
Signed-off-by: Lukasz Gniadzik <lukasz.gniadzik@mobica.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reorder fields mbedtls_ssl_handshake_params in order to save code on Arm
Thumb builds. The general idea is to put often-used fields in the direct
access window of 128 elements from the beginning of the structure.
The reordering is a human selection based on a report of field offset and
use counts, and informed by measuring the code size with various
arrangements. Some notes:
* I moved most byte-sized fields at the beginning where they're sure to be
in the direct access window.
* I moved buffering earlier because it can be around the threshold depending
on the configuration, and it's accessed in a lot of places.
* I moved several fields, including update_checksum and friends, early so
that they're guaranteed to be in the early access window.
* I tried moving randbytes or premaster to the early access window, but
I couldn't find a placement which would save code size, presumably because
they're bumping too many other fields, and they're mostly accessed through
memcpy and friends which translates to instructions that don't have an
offset for free anyway.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/ssl_cli.o: 20200 -> 20104 (diff: 96)
library/ssl_msg.o: 25978 -> 25942 (diff: 36)
library/ssl_srv.o: 22691 -> 22467 (diff: 224)
library/ssl_tls.o: 23570 -> 23390 (diff: 180)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 3012 -> 2928 (diff: 84)
library/ssl_msg.o: 2932 -> 2924 (diff: 8)
library/ssl_srv.o: 3288 -> 3232 (diff: 56)
library/ssl_tls.o: 6032 -> 5904 (diff: 128)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace bitfields mbedtls_ssl_handshake_params by bytes. This saves some
code size, and since the bitfields weren't group, this doesn't increase the
RAM usage.
Replace several ints that only store values in the range 0..255 by uint8_t.
This can increase or decrease the code size depending on the architecture
and on how the field is used. I chose changes that save code size on Arm
Thumb builds and may potentially save more after field reordering.
Leave the bitfields in struct mbedtls_ssl_hs_buffer alone: replacing them by
uint8_t slightly increases the code size.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/ssl_srv.o: 22735 -> 22691 (diff: 44)
library/ssl_tls.o: 23566 -> 23570 (diff: -4)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move fields around to have fewer accesses outside the 128-element Thumb
direct access window.
In psa_hkdf_key_derivation_t, move the large fields (output_block, prk,
hmac) after the state bit-fields. Experimentally, it's slightly better
to put hmac last.
In aead_operation_t, tag_length was outside the window. The details depend
on the sizes of contexts included in ctx. Make the large ctx be the last
field.
In mbedtls_psa_hmac_operation_t, the opad field is outside the window when
SHA-512 is enabled. Moving opad before hash_ctx only saves 4 bytes and made
the structure clumsy, so I left it alone.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/psa_crypto.o: 16246 -> 16166 (diff: 80)
library/psa_crypto_aead.o: 952 -> 928 (diff: 24)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The current definition of PSA_ALG_IS_HASH_AND_SIGN includes
PSA_ALG_RSA_PKCS1V15_SIGN_RAW and PSA_ALG_ECDSA_ANY, which don't strictly
follow the hash-and-sign paradigm: the algorithm does not encode a hash
algorithm that is applied prior to the signature step. The definition in
fact encompasses what can be used with psa_sign_hash/psa_verify_hash, so
it's the correct definition for PSA_ALG_IS_SIGN_HASH. Therefore this commit
moves definition of PSA_ALG_IS_HASH_AND_SIGN to PSA_ALG_IS_SIGN_HASH, and
replace the definition of PSA_ALG_IS_HASH_AND_SIGN by a correct one (based
on PSA_ALG_IS_SIGN_HASH, excluding the algorithms where the pre-signature
step isn't to apply the hash encoded in the algorithm).
In the definition of PSA_ALG_SIGN_GET_HASH, keep the condition for a nonzero
output to be PSA_ALG_IS_HASH_AND_SIGN.
Everywhere else in the code base (definition of PSA_ALG_IS_SIGN_MESSAGE, and
every use of PSA_ALG_IS_HASH_AND_SIGN outside of crypto_values.h), we meant
PSA_ALG_IS_SIGN_HASH where we wrote PSA_ALG_IS_HASH_AND_SIGN, so do a
global replacement.
```
git grep -l IS_HASH_AND_SIGN ':!include/psa/crypto_values.h' | xargs perl -i -pe 's/ALG_IS_HASH_AND_SIGN/ALG_IS_SIGN_HASH/g'
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a variant of PSA_ALG_RSA_PSS which currently has exactly the same
behavior, but is intended to have a different behavior when verifying
signatures.
In a subsequent commit, PSA_ALG_RSA_PSS will change to requiring the salt
length to be what it would produce when signing, as is currently documented,
whereas PSA_ALG_RSA_PSS_ANY_SALT will retain the current behavior of
allowing any salt length (including 0).
Changes in this commit:
* New algorithm constructor PSA_ALG_RSA_PSS_ANY_SALT.
* New predicates PSA_ALG_IS_RSA_PSS_STANDARD_SALT (corresponding to
PSA_ALG_RSA_PSS) and PSA_ALG_IS_RSA_PSS_ANY_SALT (corresponding to
PSA_ALG_RSA_PSS_ANY_SALT).
* Support for the new predicates in macro_collector.py (needed for
generate_psa_constant_names).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use the encoding from an upcoming version of the specification.
Add as much (or as little) testing as is currently present for Camellia.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The previous implementation was misparsed in constructs like
`if (condition) MBEDTLS_IGNORE_RETURN(...); else ...;`.
Implement it as an expression, tested with GCC, Clang and MSVC.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This macro is introduced here for use in deprecated functions. It may also
be useful in user code, so it is in a public header.
Signed-off-by: Mateusz Starzyk <mateusz.starzyk@mobica.com>
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
MBEDTLS_CHECK_RETURN_TYPICAL defaults off, but is enabled if
MBEDTLS_CHECK_RETURN_WARNING is enabled at compile time.
(MBEDTLS_CHECK_RETURN_CRITICAL is always enabled.)
The default is off so that a plausible program that builds with one version
of Mbed TLS in the default configuration will still build under the next
version.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is normally equivalent, but works even if some other header defines a
macro called warn_unused_result.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
An empty expansion is possible, but as documented its effect is to disable
the feature, so that isn't a good example. Instead, use the GCC
implementation as the default: it's plausible that it could work even on
compilers that don't advertise themselves as sufficiently GCC-like to define
__GNUC__, and if not it gives users a concrete idea of what the macro is
supposed to do.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For all of these functions, the only possible failures are a hardware
accelerator (not possible unless using an ALT implementation), an internal
error or runtime corruption.
Exception: the self-tests, which serve little purpose if their status isn't
tested.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
