The official spelling of the trade mark changed from all-lowercase "mbed"
to normal proper noun capitalization "Mbed" a few years ago. We've been
using the new spelling in new text but still have the old spelling in a
lot of text. This commit updates most occurrences of "mbed TLS":
```
sed -i -e 's/mbed TLS/Mbed TLS/g' $(git ls-files ':!ChangeLog' ':!tests/data_files/**' ':!tests/suites/*.data' ':!programs/x509/*' ':!configs/tfm*')
```
Justification for the omissions:
* `ChangeLog`: historical text.
* `test/data_files/**`, `tests/suites/*.data`, `programs/x509/*`: many
occurrences are significant names in certificates and such. Changing
the spelling would invalidate many signatures and tests.
* `configs/tfm*`: this is an imported file. We'll follow the upstream
updates.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Boolean options that modify the behavior of a module are supposed to be in
the "feature support" section, not in the "configuration options" support:
that section is documented to contain commented-out definitions with a
value, for which the comment contains the default version. In particular,
merely uncommenting a definition in the "configuration options" section is
not supposed to change anything.
Move the offending boolean options to the proper section.
This causes those options to be enabled by `config.py full` unless
explicitly excluded. For the moved options:
* Everest is already explicitly excluded.
* The ALT options need to link against a custom function, so exclude them.
* `MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_KEY_EXCHANGE` is ok for testing, and is
currently never tested in `all.sh`. With this commit, we will now test the
library with it enabled in configurations based on `full`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When all TLS 1.2 support is disabled, union mbedtls_ssl_premaster_secret was
empty, which is not valid C even if the union is never used. Fixes#6628.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some identifiers (e.g. mbedtls_free) can name either functions or
macros depending on configuration settings. For those that turn out
to name macros, first clear out any existing macro definitions to
accommodate possible unconditional bulk symbol renaming. (There
remains no standard provision for such renaming, but it's nevertheless
straightforward enough to do as desired, particularly with this change
in place.)
Signed-off-by: Aaron M. Ucko <ucko@ncbi.nlm.nih.gov>
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>
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>
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>
