Internal macros are not present as symbols, visible or usable outside
the compilation unit and it is safe to allow them to have a name without
namespace prefix.
We also allow them to start with lower case letters as some of our
internal macros already have names like that.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Application may enabled AES_ALT and define mbedtls_aes_context by its own.
The initial state of user-defined mbedtls_aes_context may not all byte zero.
In mbedtls_ctr_drbg_init, the code set all byte to zero, including the AES
context nested in the ctr_drbg context.
And in mbedtls_ctr_drbg_free, the code calls mbedtls_aes_free on an AES
context without calling mbedtls_aes_init.
If user-defined AES context requires an non-zero init, the mbedtls_aes_free
call in mbedtls_ctr_drbg_free is illegal.
This patch fix this issue by add mbedtls_aes_init in mbedtls_ctr_drbg_init.
So aes context will always be initialized to correct state.
Signed-off-by: kXuan <kxuanobj@gmail.com>
Looking at the bigger picture it is clear that if `ssl->session` is NULL,
there will be a failure much earlier, and that is well protected from,
however, the practice of dereferencing a pointer which has not been
verified in prior for validity goes against secure coding practices.
Signed-off-by: Leonid Rozenboim <leonid.rozenboim@oracle.com>
Extract functions declared in bignum_mod.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
This makes library/bignum_new.c empty and therefore it is deleted.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Extract functions declared in bignum_mod_raw.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
Signed-off-by: Janos Follath <janos.follath@arm.com>
Extract functions declared in bignum_core.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
Signed-off-by: Janos Follath <janos.follath@arm.com>
Tests function with various ECP point conditions, covering freshly
initialized, zeroed, non-zero, and freed points.
Signed-off-by: Werner Lewis <werner.lewis@arm.com>
When USE_PSA_INIT() failed because lack of seedfile, mbedtls_x509write_csr_free()
crashed when called on an unitialized mbedtls_x509write_csr struct.
This moves mbedtls_x509write_csr_init before calling USE_PSA_INIT(),
which could probably fail, and uses the same flow in x509_csr_check()
and x509_csr_check_opaque().
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This reverts commit 62c5901f0a5061a8825e19c77f88c91fea235078.
Reverting commit due the macros are meant to be local and not following the
naming convention.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
Unfortunately reusing the new function from the signed constant time
comparison is not trivial.
One option would be to do temporary conditional swaps which would prevent
qualifying input to const. Another way would be to add an additional
flag for the sign and make it an integral part of the computation, which
would defeat the purpose of having an unsigned core comparison.
Going with two separate function for now and the signed version can be
retired/compiled out with the legacy API eventually.
The new function in theory could be placed into either
`library/constant_time.c` or `library/bignum_new.c`. Going with the
first as the other functions in the second are not constant time yet and
this distinction seems more valuable for new (as opposed to belonging to
the `_core` functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- We don't check for NULL pointers this deep in the library
- Accessing a NULL pointer when the limb number is 0 as a mistake is the
very similar to any other out of bounds access
- We could potentially mandate at least 1 limb representation for 0 but
we either would need to enforce it or the implementation would be less
robust.
- Allowing zero limb representation - (NULL, 0) in particular - for zero
is present in the legacy interface, if we disallow it, the
compatibility code will need to deal with this (more code size and
opportunities for mistakes)
In summary, interpreting (NULL, 0) as the number zero in the core
interface is the least of the two evils.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The test case where there were extra limbs in the MPI failed and this
commit contains the corresponding fix as well. (We used to use the
minimum required limbs instead of the actual limbs present.)
Signed-off-by: Janos Follath <janos.follath@arm.com>
