This file had temporary MBEDTLS_xxx dependencies because it was created when
support for PSA_WANT_xxx was still incomplete. Switch to the PSA_WANT_xxx
dependencies
This fixes the bug that "PSA storage read: AES-GCM+CTR" was never executed
because there was a typo in a dependency.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Previously the check was convoluted. This has been simplified
and given a more appropriate suggestion as per gilles suggestion
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
- Reword the comment on config.h to suggest that
`MAX_INTERMEDIATE_CA` may not exist in the config.
- Add a comment explaining why the tests are more restrictive
than necessary.
Signed-off-by: Yuto Takano <yuto.takano@arm.com>
- Abstract out repetitive checks for IN and OUT content lens
- Remove unclear comment and redundant echo
- Add content length constraints in Renegotiation with fragment length test
Signed-off-by: Yuto Takano <yuto.takano@arm.com>
- Replace last remaining dependency on config.py with query_config
- Replace hard exit with `requires_config_value_at_least` and
`requires_config_value_at_most` to maintain the same effect
Signed-off-by: Yuto Takano <yuto.takano@arm.com>
- Replace calls to config.py for MAX_IN_LEN and MAX_OUT_LEN with
`get_config_value_or_default`
- Remove hard exit when MAX_IN/OUT_LEN < 4096, replace with
`requires_config_value_at_least`
Signed-off-by: Yuto Takano <yuto.takano@arm.com>
We previously introduced a safety check ensuring that if a datagram had
already been dropped twice, it would no longer be dropped or delayed
after that.
This missed an edge case: if a datagram is dropped once, it can be
delayed any number of times. Since "delay" is not defined in terms of
time (x seconds) but in terms of ordering with respect to other messages
(will be forwarded after the next message is forwarded), depending on
the RNG results this could result in an endless loop where all messages
are delayed until the next, which is itself delayed, etc. and no message
is ever forwarded.
The probability of this happening n times in a row is (1/d)^n, where d
is the value passed as delay=d, so for delay=5 and n=5 it's around 0.03%
which seems small but we still happened on such an occurrence in real
life:
tests/ssl-opt.sh --seed 1625061502 -f 'DTLS proxy: 3d, min handshake, resumption$'
results (according to debug statements added for the investigation) in
the ClientHello of the second handshake being dropped once then delayed
5 times, after which the client stops re-trying and the test fails for
no interesting reason.
Make sure this doesn't happen again by putting a cap on the number of
times we fail to forward a given datagram immediately.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
If PSA_CIPHER_ENCRYPT_OUTPUT_SIZE was called on a non symmetric key,
then a divide by zero could happen, as PSA_CIPHER_BLOCK_LENGTH will
return 0 for such a key, and PSA_ROUND_UP_TO_MULTIPLE will divide by
the block length.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Restore the optimization done in
HEAD^{/Speed up the generation of storage format test cases}
which was lost during refactoring made when adding support for
implicit usage flags.
There are still more than one call to the C compiler, but the extra
calls are only for some key usage test cases.
This is an internal refactoring. This commit does not change the
output of generate_psa_tests.py
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
