Have clearly separated code to:
* determine whether the assembly-based implementation is available;
* determine whether the intrinsics-based implementation is available;
* select one of the available implementations if any.
Now MBEDTLS_AESNI_HAVE_CODE can be the single interface for aes.c and
aesni.c to determine which AESNI is built.
Change the implementation selection: now, if both implementations are
available, always prefer assembly. Before, the intrinsics were used if
available. This preference is to minimize disruption, and will likely
be revised in a later minor release.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use a single auxiliary function to determine rk_offset, covering both
setkey_enc and setkey_dec, covering both AESNI and PADLOCK. For AESNI, only
build this when using the intrinsics-based implementation, since the
assembly implementation supports unaligned access.
Simplify "do we need to realign?" to "is the desired offset now equal to
the current offset?".
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The padlock feature is enabled if
```
defined(MBEDTLS_PADLOCK_C) && defined(MBEDTLS_HAVE_X86)
```
with the second macro coming from `padlock.h`. The availability of the
macro `MBEDTLS_PADLOCK_ALIGN16` is coincidentally equivalent to
`MBEDTLS_HAVE_X86` but this is not meaningful.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Clang is nice enough to support bitwise operators on __m128i, but MSVC
isn't.
Also, __cpuid() in MSVC comes from <intrin.h> (which is included via
<emmintrin.h>), not <cpuid.h>.
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
As of this commit, to use the intrinsics for MBEDTLS_AESNI_C:
* With MSVC, this should be the default.
* With Clang, build with `clang -maes -mpclmul` or equivalent.
* With GCC, build with `gcc -mpclmul -msse2` or equivalent.
In particular, for now, with a GCC-like compiler, when building specifically
for a target that supports both the AES and GCM instructions, the old
implementation using assembly is selected.
This method for platform selection will likely be improved in the future.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The configuration symbol MBEDTLS_AESNI_C requests AESNI support, but it is
ignored if the platform doesn't have AESNI. This allows keeping
MBEDTLS_AESNI_C enabled (as it is in the default build) when building for
platforms other than x86_64, or when MBEDTLS_HAVE_ASM is disabled.
To facilitate maintenance, always use the symbol MBEDTLS_AESNI_HAVE_CODE to
answer the question "can I call mbedtls_aesni_xxx functions?", rather than
repeating the check `defined(MBEDTLS_AESNI_C) && ...`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Uncrustify indents
```
asm("foo"
HELLO "bar"
"wibble");
```
but we would like
```
asm("foo"
HELLO "bar"
"wibble");
```
Make "bar" an argument of the macro HELLO, which makes the indentation from
uncrustify match the semantics (everything should be aligned to the same
column).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The warning is only correct if the assembly code for AESNI is built, not if
MBEDTLS_AESNI_C is activated but MBEDTLS_HAVE_ASM is disabled or the target
architecture isn't x86_64.
This is a partial fix for #7236.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Sphinx's breathe plugin cannot readily parse the Mbed TLS macros, so
define the less essential ones away at the doxygen step to reduce the
number of warnings.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When passed an empty OID, mbedtls_oid_get_numeric_string would read one
byte from the zero-sized buffer and return an error code that depends on
its value. This is demonstrated by the test suite changes, which
check that an OID with length zero and an invalid buffer pointer does
not cause Mbed TLS to segfault.
Also check that second and subsequent subidentifiers are terminated, and
add a test case for that. Furthermore, stop relying on integer division
by 40, use the same loop for both the first and subsequent
subidentifiers, and add additional tests.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
ssl_helpers.c is treated with W3 warning level in MSVC complier.
So that it's reported as error for warning of conversion from
size_t to int. This change fixes all this type of warning seen in
Microsoft Visual Studio 12.0. Besides, some potential problems of
type conversion are also handled.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
During test of component build_arm_linux_gnueabi_gcc_arm5vte and
build_arm_none_eabi_gcc_m0plus. It fails with
- error: implicit declaration of function
‘test_fail_if_psa_leaking’
It happens because test_fail_if_psa_leaking is defined in
helpers.function. This block of code is not converted into C code
while compiling ssl_helpers.c. The function has been moved to
psa_crypto_helpers.c in order to fix this build error.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
tests/src/ssl_helpers.c depends on functions defined
in library/*.c. If it's complied as an OBJECT with other c files,
cmake complains undefined reference in link stage under programs/.
Therefore, tests/src/test_helpers/ is created to hold c files with
dependency of library/*.c. Besides, tests/src/test_helper/*.c is
separated into another OBJECT, mbedtls_test_helpers, as sources
to build all test suite executables.
In addition, everest header directory is included in case
MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED is enabled.
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
Since we move many functions from test_suite_ssl.function to
ssl_helpers.c in commit bd56b03. This causes various of
build errors. This commit fixes all the build errors by
- including header files
- providing function definition
- adding guards for typedef statements and functions
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
Timing attacks can be launched by any of the main 3 attackers. Clarify
exactly how these are covered.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The block cipher exception affects both remote and local timing attacks.
Move them to the Caveats section and reference it from both the local
and the remote attack section.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Originally for the sake of simplicity there was a single category for
software based attacks, namely timing side channel attacks.
Be more precise and categorise attacks as software based whether or not
they rely on physical information.
Signed-off-by: Janos Follath <janos.follath@arm.com>
