Move all the modules that constitute
the crypto library as well as the
associated headers to tf-psa-crypto/core
for the PSA core modules and to
tf-psa-crypto/drivers/builtin/src for
the others.
The common.h file is copied instead of
being just moved as eventually they
will be different in mbedtls and
TF-PSA-Crypto. Some parts of it can be
shared though but this will be done later,
probably when adding the CMake build
system in tf-psa-crypto.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The timing module might include time.h on its own when on
a suitable platform, even if MBEDTLS_HAVE_TIME is disabled.
Co-authored-by: Tom Cosgrove <tom.cosgrove@arm.com>
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Having such implementation might cause issues for those that
expect to have a working implementation.
Having a compile-time error is better in such case.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
As a result, the copyright of contributors other than Arm is now
acknowledged, and the years of publishing are no longer tracked in the
source files.
Also remove the now-redundant lines declaring that the files are part of
MbedTLS.
This commit was generated using the following script:
# ========================
#!/bin/sh
# Find files
find '(' -path './.git' -o -path './3rdparty' ')' -prune -o -type f -print | xargs sed -bi '
# Replace copyright attribution line
s/Copyright.*Arm.*/Copyright The Mbed TLS Contributors/I
# Remove redundant declaration and the preceding line
$!N
/This file is part of Mbed TLS/Id
P
D
'
# ========================
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
In library source files, include "common.h", which takes care of
including "mbedtls/config.h" (or the alternative MBEDTLS_CONFIG_FILE)
and other things that are used throughout the library.
FROM=$'#if !defined(MBEDTLS_CONFIG_FILE)\n#include "mbedtls/config.h"\n#else\n#include MBEDTLS_CONFIG_FILE\n#endif' perl -i -0777 -pe 's~\Q$ENV{FROM}~#include "common.h"~' library/*.c 3rdparty/*/library/*.c scripts/data_files/error.fmt scripts/data_files/version_features.fmt
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
A new test for mbedtls_timing_alarm(0) was introduced in PR 1136, which also
fixed it on Unix. Apparently test results on MinGW were not checked at that
point, so we missed that this new test was also failing on this platform.
Increase the duration of the self test, otherwise it tends to fail on
a busy machine even with the recently upped tolerance. But run the
loop only once, it's enough for a simple smoke test.
mbedtls_timing_self_test fails annoyingly often when running on a busy
machine such as can be expected of a continous integration system.
Increase the tolerances in the delay test, to reduce the chance of
failures that are only due to missing a deadline on a busy machine.
Print some not-very-nice-looking but helpful diagnosis information if
the timing selftest fails. Since the failures tend to be due to heavy
system load that's hard to reproduce, this information is necessary to
understand what's going on.
mbedtls_timing_get_timer with reset=1 is called both to initialize a
timer object and to reset an already-initialized object. In an
initial call, the content of the data structure is indeterminate, so
the code should not read from it. This could crash if signed overflows
trap, for example.
As a consequence, on reset, we can't return the previously elapsed
time as was previously done on Windows. Return 0 as was done on Unix.
The POSIX/Unix implementation of mbedtls_set_alarm did not set the
mbedtls_timing_alarmed flag when called with 0, which was inconsistent
with what the documentation implied and with the Windows behavior.
Previously it was failing with errors about headers not found, which is
suboptimal in terms of clarity. Now give a clean error with pointer to the
documentation.
Do the checks in the .c files rather than check_config.h as it keeps them
closer to the platform-specific implementations.
- allow up to 12.5% security/error margin
- use larger delays
- this avoid the security/error margin being too low
The test used to fail about 1 out of 6 times on some buildbots VMs, but never
failed on the physical machines used for development.
