Initialize the verify_result field in mbedtls_ssl_session_free().
Previously we were just zeroising the entire session object, which would
yield a default 'success' value if the same object were reused.
Test that this initialisation is actually happening by setting
verify_result manually to zero and calling mbedtls_ssl_session_free() on
the session before checking its value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Since we explicitly document the value 0xFFFFFFFF or -1u as representing
'result not available', we can use it as a sensible default value
without creating an API change. Use this value instead of introducing a
new verification result value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Write a testcase to get verify_result before we have performed a
handshake and make sure that it is initialised to a failure value.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
At initialization, set the verify_result field of the ssl session to
MBEDTLS_X509_VERIFY_NOT_STARTED, rather than 0 as it is by default
currently. This prevents mbedtls_ssl_get_verify_result() from indicating
that certificate verification has passed if it is called prior to the
handshake happening.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Add a new verification result bitflag MBEDTLS_X509_VERIFY_NOT_STARTED
to use as a safe initial value for verify_result. This is better than
the current initial value which is 0 (indicating success).
Signed-off-by: David Horstmann <david.horstmann@arm.com>
As indicated in a comment, with older Clang, we need to define
`__ARM_FEATURE_CRYPTO` before we include `arm_neon.h`, which is done via
`common.h`. 4c44990d65385fd0391ead9d88a2d9f6a7e93df1
accidentally broke this. Fix it, while taking care not to include another
header before `common.h`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In `scripts/common.make`, used by `tests/Makefile` and `programs/Makefile`,
we have the following rules to build the library:
```
$(MBEDLIBS):
$(MAKE) -C ../library
```
$(MBEDLIBS) contains three library files but the command is for all
the 3 files instead of single target generation. This would cause a
race when doing parallel build. This commit fixes command so that
the recipe could generate a single library file.
Fix https://github.com/Mbed-TLS/mbedtls/issues/8229
Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Previously we were looping in one case but not even checking the other.
Let's check both cases and error out immediately. The error path should
never be taken in pratice anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In library source files, the order of things should be:
1. Define macros that affect the behavior of system headers, such as
`_POSIX_C_SOURCE` and `_GNU_SOURCE`.
2. Include the library's common header: `common.h`.
It takes care of many things, including defining the library
configuration, granting access to private fields in structures, and
activating platform-specific hacks.
3. Possibly a few header inclusions and macro definitions.
4. Guard everything else by `#if defined(MBEDTLS_XXX_C)` or some such.
Enforce this order in files that previously did things they shouldn't have
before including `common.h`. To locate the potentially
problematic files:
```
grep -m1 '^#' library/*.c | grep -v -F common.h
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Was only used in one place so far, but will be used in
rsa_gen_rand_with_inverse()'s upcoming CRT-based implementation.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Will gain a new implementation using the CRT, so we want to hide the
upcoming complexity in a dedicated function.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previous tests were backported from tf-psa-crypto and they work fine there.
However the library implementation is not the same between 3.6 and
tf-psa-crypto: in 3.6 we only prevent loading of persistent keys if their
ID is within the volatile range, but the built-in one is still allowed.
Therefore this commit fix expected return values for the 3.6 branch
when built-in keys are accessed.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
When testing what happens with when accessing a key ID in the built-in or
volatile range and a file exists in storage, we were skipping the test case
when the key existed. When the volatile or built-in key exists, the
expectations on the test case are wrong, but the test case is still useful:
we should ensure that the existence of the file doesn't somehow prevent
access to the built-in or volatile key. So, instead of skipping, change the
test assertions on the fly to ensure that we are accessing the existing key.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
