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>
PR #3959 has proven that by adding a prefix
(LIBTESTDRIVER1/libtestdriver1_ in this commit) to
all MBEDTLS/PSA_* and mbedtls/psa_* symbols of a copy
of the Mbed TLS library, we can build a library that
can be linked with the Mbed TLS library.
This commit leverages this to build a PSA test driver
library based on the Mbed TLS library code.
The cryptographic features supported by the test
library are defined by:
. a minimal configuration (in the sense of config.h),
see config_test_driver.h
. PSA_WANT_* and PSA_ACCEL_* defined macros.
The PSA_WANT_* macros have to be the same as the ones
used to build the Mbed TLS library the test driver
library is supposed to be linked to as the PSA_WANT_*
macros are used in the definition of structures and
macros that are shared by the PSA crypto core,
Mbed TLS drivers and the driver test library.
The PSA_ACCEL_* macros are intended to define the
cryptographic features that have to be removed
from the Mbed TLS library and thus supported by the
test library in test scenarios. The PSA_ACCEL_* macros
to build the test library are thus mirrored from the
ones to build the Mbed TLS library by extended the
crypto_config.h: see
crypto_config_test_driver_entension.h.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Rename test driver entry points to
libtestdriver1_<name of the Mbed TLS entry point>.
This aligns with the renaming of all Mbed TLS APIs
for the test driver library (that will be put in place
in the following commits) to avoid name conflicts
when linking it with the Mbed TLS library.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In preparation of the driver test entry points to be
provided by a test driver library, move their prototypes
to tests directory.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In psa_asymmetric_encrypt/decrypt(), always return
PSA_ERROR_INVALID_ARGUMENT if the key is a PSA key
and the algorithm is not a PSA algorithm we know
about, whether RSA is supported or not.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define test driver entry points that provide an alternative
to Mbed TLS driver entry points only when the PSA configuration
is used. Their purpose is only to test the PSA configuration
thus there is no good reason to use them out of this scope.
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>
The test entry points defined in psa_crypto_hash.c
and psa_crypto_mac.c are supposed to be exact
clones of the Mbed TLS driver entry points. Thus
the operation type should be the Mbed TLS operation
type not a test one. There was no compilation error
as the hash and cipher operation test types are
currently equal to the Mbed TLS ones.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Align RSA/ECP sign/verify hash dispatch with the
corresponding code of the library. The library
code was modified recently but not the test code
one and these modifications ease the following work.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
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>
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: 19543 -> 19559 (diff: -16)
library/ssl_msg.o: 24726 -> 24690 (diff: 36)
library/ssl_srv.o: 20462 -> 20418 (diff: 44)
library/ssl_tls.o: 20707 -> 20555 (diff: 152)
library/ssl_tls13_client.o: 7252 -> 7244 (diff: 8)
library/ssl_tls13_generic.o: 4705 -> 4693 (diff: 12)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 2876 -> 2864 (diff: 12)
library/ssl_msg.o: 3068 -> 3080 (diff: -12)
library/ssl_srv.o: 3372 -> 3340 (diff: 32)
library/ssl_tls.o: 6658 -> 6566 (diff: 92)
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.
Keep the int section after the pointer section: moving int fields first cost
a few bytes on the reference baremetal-m0plus build.
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: 19687 -> 19543 (diff: 144)
library/ssl_msg.o: 24834 -> 24726 (diff: 108)
library/ssl_srv.o: 20562 -> 20462 (diff: 100)
library/ssl_tls.o: 20907 -> 20707 (diff: 200)
library/ssl_tls13_client.o: 7272 -> 7252 (diff: 20)
library/ssl_tls13_generic.o: 4721 -> 4705 (diff: 16)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 2936 -> 2876 (diff: 60)
library/ssl_msg.o: 3080 -> 3068 (diff: 12)
library/ssl_srv.o: 3400 -> 3372 (diff: 28)
library/ssl_tls.o: 6730 -> 6658 (diff: 72)
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:
* This is the same reordering as the corresponding commit in #5189 for 2.2x.
* 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.
Results (arm-none-eabi-gcc 7.3.1, build_arm_none_eabi_gcc_m0plus build):
library/ssl_cli.o: 19763 -> 19687 (diff: 76)
library/ssl_msg.o: 24874 -> 24834 (diff: 40)
library/ssl_srv.o: 20754 -> 20562 (diff: 192)
library/ssl_tls.o: 21003 -> 20907 (diff: 96)
library/ssl_tls13_client.o: 7284 -> 7272 (diff: 12)
library/ssl_tls13_generic.o: 4749 -> 4721 (diff: 28)
library/ssl_tls13_keys.o: 5133 -> 5077 (diff: 56)
Results (same architecture, config-suite-b.h + MBEDTLS_ECDH_LEGACY_CONTEXT +
MBEDTLS_ECP_RESTARTABLE):
library/ssl_cli.o: 3000 -> 2936 (diff: 64)
library/ssl_msg.o: 3084 -> 3080 (diff: 4)
library/ssl_srv.o: 3428 -> 3400 (diff: 28)
library/ssl_tls.o: 6754 -> 6730 (diff: 24)
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 will 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_cli.o: 19759 -> 19763 (diff: -4)
library/ssl_srv.o: 20790 -> 20754 (diff: 36)
library/ssl_tls13_keys.o: 5153 -> 5133 (diff: 20)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
TLS1.3 MVP would benefit from a different curve group preference order
in order to not cause a HelloRetryRequest (which are not yet handled),
however changing the curve group preference order would affect both
TLS1.2 and TLS1.3, which is undesirable for something rare that can
be worked around.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
