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.
- 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.
Found with Clang's `scan-build` tool.
When get_timer() is called with `reset` set to 1, the value of
t->start.tv_sec is used as a rvalue without being initialized first.
This is relatively harmless because the result of get_timer() is not
used by the callers when called in "reset mode". However, scan-build
prints a warning.
Silence the warning by only calculating the delta on non-reset runs,
returning zero otherwise.
