Use `uint_fast8_t` instead of `unsigned char` in various loop-type
situations. This avoids the need for a 16 or 32-bit system to insert
explicit narrow-to-8-bit instructions.
Not the result of an exhaustive source analysis, rather inspecting
the disassembly output for a cut-down Cortex-M0+ build looking for
UXTB etc instructions, so there could well be more in the complete
configuration.
Signed-off-by: Kevin Bracey <kevin.bracey@arm.com>
Old GCC (pre-5?) natively use divided syntax, so we must put it back
after changing it.
More recent GCCs natively use unified syntax, and themselves are
surrounding our blocks with divided/unified directives for backwards
compatibility, so we don't need to restore for those.
Signed-off-by: Kevin Bracey <kevin.bracey@arm.com>
Naked functions and basic assembler don't seem to work reliably - basic
assembler is assumed to not change registers or memory, and there does
not appear to be any special handling of naked functions in this regard.
Signed-off-by: Kevin Bracey <kevin.bracey@arm.com>
Since the mbed TLS implementation of rng wrapper returns the size of random
data generated upon success - check for it explicitly.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
* upstream/pr/2945:
Rename macro MBEDTLS_MAX_RAND_DELAY
Update signature of mbedtls_platform_random_delay
Replace mbedtls_platform_enforce_volatile_reads 2
Replace mbedtls_platform_enforce_volatile_reads
Add more variation to random delay countermeasure
Add random delay to enforce_volatile_reads
Update comments of mbedtls_platform_random_delay
Follow Mbed TLS coding style
Add random delay function to platform_utils
Duplicating the g_rng_function variable in ecc_dsa.c means it's not the same
as set in ecc.c, resulting if no randomisation here. The proper way to access
the RNG function from outside ecc.c is uECC_get_rng(), so use that.
This is a side-port of upstream commit
87d74dd8d64a99aaa188961fe763d0841c5abfef
I've verified that there are no other occurrences (the duplication of
g_rng_function in ecc_dh.c had already been removed earlier when centralising
projective coordinate randomisation to mult_safer()).
Found by the IAR compiler.
While at it, make 'diff' non-volatile in uECC_check_curve_integrity(), as
there is no good reason to make it volatile, and making it volatile only
increases the code size and the burden of defining access ordering.
This commit first changes the return convention of EccPoint_mult_safer() so
that it properly reports when faults are detected. Then all functions that
call it need to be changed to (1) follow the same return convention and (2)
properly propagate UECC_FAULT_DETECTED when it occurs.
Here's the reverse call graph from EccPoint_mult_safer() to the rest of the
library (where return values are translated to the MBEDTLS_ERR_ space) and test
functions (where expected return values are asserted explicitly).
EccPoint_mult_safer()
EccPoint_compute_public_key()
uECC_compute_public_key()
pkparse.c
tests/suites/test_suite_pkparse.function
uECC_make_key_with_d()
uECC_make_key()
ssl_cli.c
ssl_srv.c
tests/suites/test_suite_pk.function
tests/suites/test_suite_tinycrypt.function
uECC_shared_secret()
ssl_tls.c
tests/suites/test_suite_tinycrypt.function
uECC_sign_with_k()
uECC_sign()
pk.c
tests/suites/test_suite_tinycrypt.function
Note: in uECC_sign_with_k() a test for uECC_vli_isZero(p) is suppressed
because it is redundant with a more thorough test (point validity) done at the
end of EccPoint_mult_safer(). This redundancy was introduced in a previous
commit but not noticed earlier.
We don't really need a secure hash for that, something like CRC32 would
probably be enough - but we have SHA-256 handy, not CRC32, so use that for the
sake of simplicity.
