Ideally the result of the generator would conform to the code style, but
this would be difficult, especially with respect to the placement of line
breaks in long logical lines. So, to avoid surprises when checking the style
of generated files (which happens in releases and in long-time support
branches), systematically skip generated files.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Allow check_names.py to detect declarations of the form:
enum some_enum_name {
This pattern has only just appeared due to code style correction, which
explains why the issue was not previously noticed.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The script was parsing the output from `make lcov` to extract numbers and
calculate percentages. But everything including the percentages is already
present in the output of `make lcov`, just with a slightly different
presentation. So replace all this by a simple extraction of the relevant
lines from the output of `make lcov`.
This is more robust than the previous code, which relied on `tail -n4` to
extract relevant lines, which broke when `make lcov` started to emit one
extra line at the end.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the basic/XXX=core test cases, use odd upper bounds, because the mod
version of random() only supports odd upper bounds (the upper bound is a
modulus and the mod modules only support odd moduli).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When including <test/bignum_helpers.h>, the library/ directory now needs to
be on the include path.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move bignum-related helper functions to their own files under tests/include
and tests/src. The primary motivation is that a subsequent commit will make
bignum_helpers.h include library/bignum*.h, but we want to be able to
include <test/helpers.h> without having the library directory on the include
path (we do this in some programs under programs/ intended for testing).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mpi_core_random_basic and mpi_random_values must generate the same random
sequences in order to get the expected test coverage (where we know we'll
hit certain numbers of retries). Facilitate this by defining the RNG seed
only once.
Fix the seed to explicitly list all 16 words of the key. This isn't strictly
required (missing initializer fields get the value zero), but it's clearer.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is meant to adapt to the new library design in which
SHA224 and SHA256 can be built independently from each other.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
This is meant to adapt to the new library design in which
SHA384 and SHA512 can be built independently from each other.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Previously the same test was repeated twice.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Tests are refactored to generate separate cases for 32-bit and 64-bit
limbs using arch_split. Duplicate arguments and branching in the test
function is removed.
Signed-off-by: Werner Lewis <werner.lewis@arm.com>
This is not new, it had always been the case, just not documented.
Pointed out by depends.py pkalgs (again, now that restartable is part of
full).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
muladd() (restartable or not) is only available when at least one short
weirstrass curve is enabled.
Found by depends.py curves (now that restartable is part of full).
Also, document that restartable only work for short weierstrass curves
(actually unrelated, but this made me think of that).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous commit declared that some tests cases in ssl-opt.sh depend
on USE_PSA being disabled, which is the right thing to do.
We had a check that forbade that - it was mainly meant to prevent
accidental re-introduction of such dependencies after we cleaned up a
number of cases where it was not warranted, but already at the time that
was controversial [1]. Now it's preventing us from doing the right
thing, so let's just remove it.
[1]: https://github.com/Mbed-TLS/mbedtls/pull/5742#discussion_r855112412
See also https://github.com/Mbed-TLS/mbedtls/pull/5907/ which also
removes this for a similar reason.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This fixes the two failures in test_suite_x509parse when both
ECP_RESTARTABLE and USE_PSA_CRYPTO are enabled.
The failure happened because the operation is dispatched to PSA when
restart is disabled (max_ops == 0).
Previously it was correct for this test function not to initialize PSA,
because it depends on ECP_RESTARTABLE which used to conflict with
USE_PSA_CRYPTO, but that's no longer the case.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The random-in-nrange test code has auxiliary functions that are common to all
the interfaces (core, mod_raw (upcoming), mod (upcoming), legacy), and does
some differential testing to check that all the layers consume the RNG in
the saame way. Test them all in the same test suite.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Run the main test suites after running code style correction to check
that code style correction does not break these tests.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
It might not be obvious that this option goes beyond adding new
functions, but also automagically modifies the behaviour of TLS
in some circumstances. Moreover, the exact modifications and
circumstances were not documented anywhere outside the ChangeLog.
Fix that.
While at it, adjust the test that checks no restartable behaviour with
other key exchanges, to use a key exchange that allows cert-based client
authentication so that we can check that this is not restartable either.
We don't have any automated test checking that the server is never
affected. That would require adding an ec_max_ops command-line option to
ssl_server2 that never has any effect, just to check that it indeed
doesn't. I'm not sure that's worth it. I tested manually and could
confirm that the server never has restartable behaviour, even for the
parts that are shared between client and server such as cert chain
verification.
Note (from re-reading the code): all restartable behaviour is controlled
by the flag ssl->handshake->ecrs_enabled which is only client-side with
the ECDHE-ECDSA key exchange (TLS 1.2).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Test some cases where mbedtls_mpi_core_random() or mbedtls_mpi_random()
should return MBEDTLS_ERR_MPI_NOT_ACCEPTABLE. These test cases use a very
small range that makes the NOT_ACCEPTABLE case likely. The test code uses a
deterministic RNG whose implementation is in the test framework, so we know
that the tests will pass reproducibly unless the implementation the test
framework changes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test function mpi_random_many() is the main function for testing the
get-random-in-range function. It validates that the random generator's
output is within the desired range, and performs some basic statistical
checks including checking that small ranges are covered exhaustively.
Switch this function from testing mbedtls_mpi_random() to testing
mbedtls_mpi_core_random(). This does not reduce the test coverage of
mbedtls_mpi_random() because the same properties are now validated
indirectly via mpi_random_values() which checks that mbedtls_mpi_random()
and mbedtls_mpi_core_random() produce identical values for identical inputs.
As of this commit, mpi_random_many() still uses some legacy mpi functions
internally because the corresponding functions don't exist yet in core.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For good cases, test that mbedtls_mpi_random() produces the same output as
mbedtls_mpi_core_random().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Compare a single-limb MPI with a multi-limb MPI. This is rather ad hoc, but
will be useful for mbedtls_mpi_core_random.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Added mixed cases:
- server using opaque password, while client not
- client using opaque password, while server not
Added a test with mismatched passwords in case both server and
client are using opaque passwords (the same test was already
present for the non-opaque case)
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
This is already covered by other already existing cases such as
"component_test_full_cmake_gcc_asan" which build with
"config.py full" and run all "ssl-opt.sh" test cases.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
