The goal of testing with GCC 15 is to validate fixes for
https://github.com/Mbed-TLS/mbedtls/issues/9814 . The bug is present in
multiple places, and some of them affect third-party drivers but not our
built-in implementation. (The bug is that driver contexts might not be
zero-initialized, but some of our built-in implementations happen not to
care about this.) Thus, enable the test drivers in the test component that
uses GCC 15, to gain the extra checks performed in the driver wrappers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is a new warning in GCC 15 that our code base triggers in many places.
Silence it for the time being.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The OID module is used by both crypto and X.509. It has moved to the
`tf-psa-crypto` subdirectory, and the sibling commit
08d8cc57db removes this subdirectory from the
`mbedtls` repository in order to make `tf-psa-crypto` a submodule. We want
to access the relevant parts directly from X.509 rather than go through the
crypto repository, because OID functions are only accessible as private
interfaces, and crypto doesn't know when a particular OID function is needed
in the build since it depends on X.509 configuration options.
Make a copy of the OID module and its unit tests. In a follow-up, the X.509
module will switch to consuming this copy rather than the one that went into
TF-PSA-Crypto.
Rename the files from `*oid*` to `*x509_oid*` to follow the naming
convention that submodules of X.509 are prefixed with `x509`. This also
avoids file name clashes with TF-PSA-Crypto.
Since OID is not a public interface of Mbed TLS 4.x, move the header file
into `library`.
This commit only makes the files available. Subsequent commits will take
care of making these files used in the build.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Parsing of CRT files with message's hash alg different from the MGF1 was
allowed in the past, but now it fails. So we need to move/adapt tests
relying on this feature, from a "verify" scope to a "parse" one.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Import component_test_platform_get_entropy_alt() from its counterpart
in TF-PSA-Crypto repo.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use the proper Clang C++ compiler to build C++ code otherwise the C
compiler will fail because std::cout() is unknown in
"cpp_dummy_build.cpp".
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use alternative implementation of mbedtls_platform_get_entropy() since
the default one lives in "platform.c" and that one is excluded in
this test component.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
By default C++ code would be compiled with GNU while C with Clang and
this can create problems at link time. In order to prevent this we
use Clang for both.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This is necessary to let entropy being able to gather entropy data from
the native platform source.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
We were not making enough room. We want to move everything from the
place where we are going to insert the new record.
This was not causing failures because the code does not look at the
content after the inserted record, because it correctly returns an error
when seeing the inserted record. But as a matter on principle, the test
code should be doing what it says: just insert a new record but leave
a valid fragment after it.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This one is overly tight: TLS 1.3 actually only depends on
ChachaPoly || (AES && (GCM || CCM))
Furthermore, this should really be reflected in check_config.h.
Individual test cases should be able to just request PROTO_TLS1_3 and
know that there is ciphersuite that works.
However, resolving that seems out of scope for this PR. (It would also
involve updating depends.py for example.)
So, use a dependency that's stricted than necessary. IMO it's still good
enough as most configs we test will have ChachaPoly. However it would be
good to revisit this when a cleaner solution is implemented.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The function depends on MBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED which is
basically
MBEDTLS_SSL_TLS1_3_KEY_EXCHANGE_MODE_EPHEMERAL_ENABLED ||
MBEDTLS_KEY_EXCHANGE_WITH_CERT_ENABLED
The individual test cases depend on the specific TLS version.
This is not precise enough. In a build with both TLS versions enabled,
we could have cert-based key exchange in one version but not in the
other. So, we need the 1.3 tests to depend on the 1.3 cert-based key
exchange and similarly for 1.2.
For 1.2, cert-based key exchange means ECDHE-{RSA,ECDSA} or
ECDH-{RSA,ECDSA}. Since the test function sets an ECC cert for the
server, we want one of the ECDSA ones. So, the minimal dependency would
be ECDH_ECDSA || ECDHE_ECDSA. Since dependencies with || are
inconvenient to express, and anyway ECDH_ECDSA (static ECDH) is
something we'd like to remove in 4.0 if we can find the time, I chose to
just depend on ECDHE_ECDSA.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
These are not optimal. For example, the tests should in principle be
able to run in builds without ECDSA, by using RSA certs instead. Ideally
PSK should work too.
However, getting optimal dependencies would be a lot of work that's
largely orthogonal to the purpose of this PR, so we'll settle for good
enough.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Simulate the server closing the connection after a partial handshake
message.
These test cases don't send a close_notify alert. The test cases
"insert alert record" exercise what happens if the server sends an alert.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
