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>
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>
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>
When MBEDTLS_USE_PSA_CRYPTO is enabled, the application must call
psa_crypto_init() before directly or indirectly calling cipher or PK code
that will use PSA under the hood. Document this explicitly for some
functions.
To avoid clutter, this commit only documents the need to call
psa_crypto_init() in common, non-obvious cases: using a PK object that was
not constructed using PSA, X.509 processing, or setting up an SSL context.
Functions that are normally only called after such a function (for example,
using a cipher or PK context constructed from a PSA key), or where the need
for PSA is obvious because they take a key ID as argument, do not need more
explicit documentaion.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
With this change, "--list-components" will not list
"build_armcc" on the system which is not installed
with Arm Compilers.
Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
escalates into a buffer overflow in the application code
Signed-off-by: Stephan Koch <koch@oberon.ch>
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
