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>
This is in preparation for running it multiple times with different
alignments.
This commit also fixes the fact that we weren't calling mbedtls_aes_free()
on the context (we still aren't if the test fails). It's not an issue except
possibly in some ALT implementations.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't use all-bytes zero as a string, it's harder to debug.
This commit uses the test vectors from FIPS 197 appendix C.
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>
There were some dependencies that are now automatically satisfied by the
detect_required_features() function.
After this check there should be no redundant requirement for:
- requires_pk_alg "ECDSA"
- requires_any_configs_enabled $TLS1_2_KEY_EXCHANGES_WITH_ECDSA_CERT
- requires_any_configs_enabled $TLS1_2_KEY_EXCHANGES_WITH_CERT
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This was a leftover from some debug activity that unfortunately ended up
in previous commits.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
