It's a bit strange for tests/Makefile to clean up in library, but OTOH
it's also tests/Makefile that copies this file there.
Regardless, there was no place that cleaned up this file, and it needs to
be removed somewhere.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now that the script only makes before-after comparison, it no longer
makes sense to ignore some test suites.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
For now, ignore test suites that don't have parity even is they should.
The purpose is just to prepare the infrastructure and map the work.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is the basis for future work, we'll want to make sure everything
passes in this component.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Slightly re-organize (accel list at the top).
No need to disable USE_PSA or TLS 1.3 because they're already that way
in the default config.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Move the *INDENT-ON* annotation to the end of the file so that
uncrustify does not restyle the later sections (since it introduces a
risk of future problems).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
Two macros are also defined in headers in the PSA Compliance test suite, so
the test suite would fail to build if we changed the definitions. Preserve
those definitions. Technically this is a bug in the test suite, since having
extra spaces (or even a completely different constant expression with the
same value) would still be compliant. Bug reported as
https://github.com/ARM-software/psa-arch-tests/issues/337
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some preprocessor macro definitions must have a specific expansion so that
the same macro name can be defined in different products. The definition of
having the same expansion (per the C language specification) means the same
sequence of tokens, and also the same absence/presence of spacing between
tokens.
For PSA error code definitions, the specific expansion is mandated by the
PSA Status code specification and the PSA Crypto API specification. In
particular, there must not be a space between (psa_status_t) and the
numerical value (whereas K&R would put a space).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The inline assembly defined in bn_mul.h confuses code style parsing,
causing code style correction to fail. Disable code style correction for
the whole section gated by "#if defined(MBEDTLS_HAVE_ASM)" to prevent
this.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Some PSA curves' symbols (PSA_WANT_) were not matching the corresponding
MBEDTLS_ECP_DP_. This was fixed together with the removal of extra code
when DEBUG_C is not enabled.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
mbedtls_test_psa_setup_key_derivation_wrap() returns 1 for success, 0
for error, so the test here was wrong.
This is just a hotfix in order to avoid a testing gap. Larger issues not
addressed here:
- I don't think we should just exit and mark the test as passed; if
we're not doing the actual testing this should be marked as SKIP.
- Returning 1 for success and 0 for failure is a violation of our
documented coding guidelines. We're also supposed to test with == 0 or
!= 0. Having consistent conventions is supposed to help avoid errors
like this.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The following code:
#ifndef asm
#define asm __asm
#endif
causes Uncrustify to stop correcting the rest of the file. This may be
due to parsing the "asm" keyword in the definition.
Work around this by wrapping the idiom in an *INDENT-OFF* comment
wherever it appears.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Otherwise, in builds without PKSC1_V15, tests that are supposed to
accept the certificate will fail, because once the cert is OK they will
move on to checking the CRL and will choke on its non-PSS signature.
Tests that are supposed to reject the cert due to an invalid signature
from the CA will not check the CRL because they don't recognize the CA
as valid, so they have no reason to check the CA's CRL. This was hiding
the problem until the recent commit that added a test where the cert is
supposed to be accepted.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
