Tell the GCC compiler that pointers to types "mbedtls_uintXX_unaligned_t"
(where XX is 16, 32 or 64) might alias with other types. This helps at
high optimizations level (i.e. "-O3") so that the compiler does not mess
up with instruction reordering and memory accesses.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
MBEDTLS_ALIGNMENT_DISABLE_EFFICENT_UNALIGNED_ACCESS is used to forcedly
prevent MBEDTLS_EFFICIENT_UNALIGNED_ACCESS from being set. This prevents
optimizations from being used on x86 which is useful for testing
purposes.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is meant to test a bug found on:
- Little endian platforms other than x86 or ARM (these have specific
optimizations available);
- GCC versions from 10 to 14.2 (below and above are fine);
- Optimization level "-O3" (lower levels are fine).
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This patch adjusts the include order so that some ACLE
intrinsics macros are configured before
the inclusion of `neon.h`. This fixes issues with older
clang compilers but has no effect in modern versions.
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
As indicated in a comment, with older Clang, we need to define
`__ARM_FEATURE_CRYPTO` before we include `arm_neon.h`, which is done via
`common.h`. 4c44990d65
accidentally broke this. Fix it, while taking care not to include another
header before `common.h`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In `scripts/common.make`, used by `tests/Makefile` and `programs/Makefile`,
we have the following rules to build the library:
```
$(MBEDLIBS):
$(MAKE) -C ../library
```
$(MBEDLIBS) contains three library files but the command is for all
the 3 files instead of single target generation. This would cause a
race when doing parallel build. This commit fixes command so that
the recipe could generate a single library file.
Fix https://github.com/Mbed-TLS/mbedtls/issues/8229
Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Previously we were looping in one case but not even checking the other.
Let's check both cases and error out immediately. The error path should
never be taken in pratice anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In library source files, the order of things should be:
1. Define macros that affect the behavior of system headers, such as
`_POSIX_C_SOURCE` and `_GNU_SOURCE`.
2. Include the library's common header: `common.h`.
It takes care of many things, including defining the library
configuration, granting access to private fields in structures, and
activating platform-specific hacks.
3. Possibly a few header inclusions and macro definitions.
4. Guard everything else by `#if defined(MBEDTLS_XXX_C)` or some such.
Enforce this order in files that previously did things they shouldn't have
before including `common.h`. To locate the potentially
problematic files:
```
grep -m1 '^#' library/*.c | grep -v -F common.h
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Was only used in one place so far, but will be used in
rsa_gen_rand_with_inverse()'s upcoming CRT-based implementation.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Will gain a new implementation using the CRT, so we want to hide the
upcoming complexity in a dedicated function.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previous tests were backported from tf-psa-crypto and they work fine there.
However the library implementation is not the same between 3.6 and
tf-psa-crypto: in 3.6 we only prevent loading of persistent keys if their
ID is within the volatile range, but the built-in one is still allowed.
Therefore this commit fix expected return values for the 3.6 branch
when built-in keys are accessed.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
When testing what happens with when accessing a key ID in the built-in or
volatile range and a file exists in storage, we were skipping the test case
when the key existed. When the volatile or built-in key exists, the
expectations on the test case are wrong, but the test case is still useful:
we should ensure that the existence of the file doesn't somehow prevent
access to the built-in or volatile key. So, instead of skipping, change the
test assertions on the fly to ensure that we are accessing the existing key.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
