A positive option looks better, but comes with the following compatibility
issue: people using a custom config.h that is not based on the default
config.h and need TLS support would need to manually change their config in
order to still get TLS.
Work around that by making the public option negative. Internally the positive
option is used, though.
In the future (when preparing the next major version), we might want to switch
back to a positive option as this would be more consistent with other options
we have.
We called in tinycrypt in the file names, but uecc in config.h, all.sh and
other places, which could be confusing. Just use tinycrypt everywhere because
that's the name of the project and repo where we took the files.
The changes were made using the following commands (with GNU sed and zsh):
sed -i 's/uecc/tinycrypt/g' **/*.[ch] tests/scripts/all.sh
sed -i 's/MBEDTLS_USE_UECC/MBEDTLS_USE_TINYCRYPT/g' **/*.[ch] tests/scripts/all.sh scripts/config.pl
Motivation is similar to NO_UDBL_DIVISION.
The alternative implementation of 64-bit mult is straightforward and aims at
obvious correctness. Also, visual examination of the generate assembly show
that it's quite efficient with clang, armcc5 and arm-clang. However current
GCC generates fairly inefficient code for it.
I tried to rework the code in order to make GCC generate more efficient code.
Unfortunately the only way to do that is to get rid of 64-bit add and handle
the carry manually, but this causes other compilers to generate less efficient
code with branches, which is not acceptable from a side-channel point of view.
So let's keep the obvious code that works for most compilers and hope future
versions of GCC learn to manage registers in a sensible way in that context.
See https://bugs.launchpad.net/gcc-arm-embedded/+bug/1775263
When printing an option's value, print a newline at the end.
When the requested option is missing, fail with status 1 (the usual
convention for "not found") rather than -1 (which has a
system-dependent effect).
scripts/config.pl would always rewrite config.h if it was reading it.
This commit changes it to not modify the file when only reading is
required, i.e. for the get command.
Also, die if writing config.h fails (e.g. disk full).
Between 2.5.0 and 2.6.0, "scripts/config.pl get MBEDTLS_XXX" was fixed
for config.h lines with a comment at the end, but that broke the case
of macros with an empty expansion. Support all cases.
The effect of `config.pl full` on 'negative' options such as
`NO_PLATFORM_ENTROPY` is usually inverted, but `MBEDTLS_RSA_NO_CRT` was not
included in the list of such options. This commit adds it.
Fixes many typos, and errors in comments.
* Clarifies many comments
* Grammar correction in config.pl help text
* Removed comment about MBEDTLS_X509_EXT_NS_CERT_TYPE.
* Comment typo fix (Dont => Don't)
* Comment typo fix (assure => ensure)
* Comment typo fix (byes => bytes)
* Added citation for quoted standard
* Comment typo fix (one complement => 1's complement)
The is some debate about whether to prefer "one's complement", "ones'
complement", or "1's complement". The more recent RFCs related to TLS
(RFC 6347, RFC 4347, etc) use " 1's complement", so I followed that
convention.
* Added missing ")" in comment
* Comment alignment
* Incorrect comment after #endif
Add a switch that turns entropy collecting off entirely, but enables
mbed TLS to run in an entirely unsafe mode. Enables to test mbed TLS
on platforms that don't have their entropy sources integrated yet.
The script config.pl fails when setting a #define symbol if the symbol isn't
already in the configuration header. This adds an option '--force' to append
the symbol to the end of the file if it isn't already present.
Also clarified usage, and added copyright to the config.pl.
Otherwise we get warnings that some documentation items don't have
corresponding #define, and more importantly the corresponding snippets are not
included in the output.
For that we need a modified version of the "full" argument for config.pl.
Also, the new CMakeLists.txt target only works on Unix (which was already the
case of the Makefile target). Hopefully this is not an issue as people are
unlikely to need that target on Windows.
