The previous version had secret-dependent memory accesses. While it was
probably not an issue in practice cause the two bytes of the array are
probably on the same cache line anyway, as a matter of principle this should
be avoided.
Due to inconsistent freeing strategy in pkparse.c the sample mutex
implementation in threading.c could lead to undefined behaviour by
destroying the same mutex several times.
This fix prevents mutexes from being destroyed several times in the
sample threading implementation.
The library/net.c and its corresponding include/mbedtls/net.h file are
renamed to library/net_sockets.c and include/mbedtls/net_sockets.h
respectively. This is to avoid naming collisions in projects which also
have files with the common name 'net'.
Allow the size of the entry_name character array in x509_crt.c to be
configurable through a macro in config.h. entry_name holds a
path/filename string. The macro introduced in
MBEDTLS_X509_MAX_FILE_PATH_LEN.
Ensure that the entropy self test always fails whenever
MBEDTLS_TEST_NULL_ENTROPY is defined. This is because the option is
meant to be for testing and development purposes rather than production
quality software. Also, this patch enhances the documentation for
mbedtls_entropy_source_self_test() and mbedtls_entropy_self_test().
Instead of polling the hardware entropy source a single time and
comparing the output with itself, the source is polled at least twice
and make sure that the separate outputs are different.
The self test is a quick way to check at startup whether the entropy
sources are functioning correctly. The self test only polls 8 bytes
from the default entropy source and performs the following checks:
- The bytes are not all 0x00 or 0xFF.
- The hardware does not return an error when polled.
- The entropy does not provide data in a patter. Only check pattern
at byte, word and long word sizes.
In platform.c, made the time functions dependent on the configuration
MBEDTLS_HAVE_TIME to fix a build break where the functions could be
built but the mbedtls_time_t was not defined.
Separates platform time abstraction into it's own header from the
general platform abstraction as both depend on different build options.
(MBEDTLS_PLATFORM_C vs MBEDTLS_HAVE_TIME)
This commit fixes following warning:
> CC: aes.c
> aes.c: In function 'mbedtls_aes_self_test':
> aes.c:1225:19: error: unused variable 'iv' [-Werror=unused-variable]
> unsigned char iv[16];
> ^
> cc1: all warnings being treated as errors
If the option MBEDTLS_TEST_NULL_ENTROPY is enabled, the cmake generated
makefile will generate an error unless a UNSAFE_BUILD switch is also enabled.
Equally, a similar warning will always be generated if the Makefile is built,
and another warning is generated on every compilation of entropy.c.
This is to ensure the user is aware of what they're doing when they enable the
null entropy option.
Update the NV entropy seed before generating any entropy for outside
use. The reason this is triggered here and not in mbedtls_entropy_init(),
is that not all entropy sources mights have been added at that time.
Introduces mbedtls_nv_seed_read() and mbedtls_nv_seed_write().
The platform-layer functions are only available when
MBEDTLS_ENTROPY_NV_SEED is enabled.
Add a switch that turns entropy collecting off entirely, but enables
mbed TLS to run in an entirely unsafe mode. Enables to test mbed TLS
on platforms that don't have their entropy sources integrated yet.
Commit daf534d from PR #457 breaks the build. This may reintroduce a
clang-analyse warning, but this is the wrong fix for that.
The fix removed a call to mbedtls_ecp_curve_info_from_grp_id() to find
the curve info. This fix adds that back in.
The check is already effectively performed later in the function, but
implicitly, so Clang's analysis fail to notice the functions are in
fact safe. Pulling the check up to the top helps Clang to verify the
behaviour.
Since the buffer is used in a few places, it seems Clang isn't clever
enough to realise that the first byte is never touched. So, even though
the function has a correct null check for ssl->handshake, Clang
complains. Pulling the handshake type out into its own variable is
enough for Clang's analysis to kick in though.
The function appears to be safe, since grow() is called with sensible
arguments in previous functions. Ideally Clang would be clever enough to
realise this. Even if N has size MBEDTLS_MPI_MAX_LIMBS, which will
cause the grow to fail, the affected lines in montmul won't be reached.
Having this sanity check can hardly hurt though.
It is used only by `mbedtls_sha512_process()`, and in case `MBEDTLS_SHA512_PROCESS_ALT` is defined, it still cannot be reused because of `static` declaration.
On x32 systems, pointers are 4-bytes wide and are therefore stored in %e?x
registers (instead of %r?x registers). These registers must be accessed using
"addl" instead of "addq", however the GNU assembler will acccept the generic
"add" instruction and determine the correct opcode based on the registers
passed to it.
The server code parses the client hello extensions even when the
protocol is SSLv3 and this behaviour is non compliant with rfc6101.
Also the server sends extensions in the server hello and omitting
them may prevent interoperability problems.
Commit daf534d from PR #457 breaks the build. This may reintroduce a
clang-analyse warning, but this is the wrong fix for that.
The fix removed a call to mbedtls_ecp_curve_info_from_grp_id() to find
the curve info. This fix adds that back in.
The check is already effectively performed later in the function, but
implicitly, so Clang's analysis fail to notice the functions are in
fact safe. Pulling the check up to the top helps Clang to verify the
behaviour.
Since the buffer is used in a few places, it seems Clang isn't clever
enough to realise that the first byte is never touched. So, even though
the function has a correct null check for ssl->handshake, Clang
complains. Pulling the handshake type out into its own variable is
enough for Clang's analysis to kick in though.
The function appears to be safe, since grow() is called with sensible
arguments in previous functions. Ideally Clang would be clever enough to
realise this. Even if N has size MBEDTLS_MPI_MAX_LIMBS, which will
cause the grow to fail, the affected lines in montmul won't be reached.
Having this sanity check can hardly hurt though.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
The callback typedefs defined for mbedtls_ssl_set_bio() and
mbedtls_ssl_set_timer_cb() were not used consistently where the callbacks were
referenced in structures or in code.
- basicContraints checks are done during verification
- there is no need to set extensions that are not present to default values,
as the code using the extension will check if it was present using
ext_types. (And default values would not make sense anyway.)
- document why we made that choice
- remove the two TODOs about checking hash and CA
- remove the code that parsed certificate_type: it did nothing except store
the selected type in handshake->cert_type, but that field was never accessed
afterwards. Since handshake_params is now an internal type, we can remove that
field without breaking the ABI.
We don't implement anonymous key exchanges, and we don't intend to, so it can
never happen that an unauthenticated server requests a certificate from us.
After the record contents are decompressed, in_len is no longer
accessed directly, only in_msglen is accessed. in_len is only read by
ssl_parse_record_header() which happens before ssl_prepare_record_contents().
This is also made clear by the fact that in_len is not touched after
decrypting anyway, so if it was accessed after that it would be wrong unless
decryption is used - as this is not the case, it show in_len is not accessed.
Previously it was failing with errors about headers not found, which is
suboptimal in terms of clarity. Now give a clean error with pointer to the
documentation.
Do the checks in the .c files rather than check_config.h as it keeps them
closer to the platform-specific implementations.
It is used only by `mbedtls_sha512_process()`, and in case `MBEDTLS_SHA512_PROCESS_ALT` is defined, it still cannot be reused because of `static` declaration.
armar doesn't understand the syntax without dash. OTOH, the syntax with dash
is the only one specified by POSIX, and it's accepted by GNU ar, BSD ar (as
bundled with OS X) and armar, so it looks like the most portable syntax.
fixes#386
* yanesca/iss309:
Improved on the previous fix and added a test case to cover both types of carries.
Removed recursion from fix#309.
Improved on the fix of #309 and extended the test to cover subroutines.
Tests and fix added for #309 (inplace mpi doubling).
On x32 systems, pointers are 4-bytes wide and are therefore stored in %e?x
registers (instead of %r?x registers). These registers must be accessed using
"addl" instead of "addq", however the GNU assembler will acccept the generic
"add" instruction and determine the correct opcode based on the registers
passed to it.
See for example page 8 of
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
The previous constant probably came from a typo as it was 2^26 - 2^5 instead
of 2^36 - 2^5. Clearly the intention was to allow for a constant bigger than
2^32 as the ull suffix and cast to uint64_t show.
fixes#362
By looking just at that test, it looks like 2 + dn_size could overflow. In
fact that can't happen as that would mean we've read a CA cert of size is too
big to be represented by a size_t.
However, it's best for code to be more obviously free of overflow without
having to reason about the bigger picture.
In case an entry with the given OID already exists in the list passed to
mbedtls_asn1_store_named_data() and there is not enough memory to allocate
room for the new value, the existing entry will be freed but the preceding
entry in the list will sill hold a pointer to it. (And the following entries
in the list are no longer reachable.) This results in memory leak or a double
free.
The issue is we want to leave the list in a consistent state on allocation
failure. (We could add a warning that the list is left in inconsistent state
when the function returns NULL, but behaviour changes that require more care
from the user are undesirable, especially in a stable branch.)
The chosen solution is a bit inefficient in that there is a time where both
blocks are allocated, but at least it's safe and this should trump efficiency
here: this code is only used for generating certificates, which is unlikely to
be done on very constrained devices, or to be in the critical loop of
anything. Also, the sizes involved should be fairly small anyway.
fixes#367
