We don't commit *.o files anywhere, not even as test data. So ignore them
everywhere.
Also remove a redundant ignore of *.exe in a subdirectory.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Note: RSA is not supported in mbedtls-2.28 for opaque wrapping
so it was removed from test_suite_pkwrite.data.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
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>
