Fix a race condition in `mbedtls_aes_ni_has_support()` with some compilers.
A compiler could hoist the assignment `done = 1` above the assignment to `c`,
in which case if two threads call `mbedtls_aes_ni_has_support()` at almost
the same time, they could be interleaved as follows:
Initially: done = 0, c = 0
thread A thread B
if (!done)
done = 1; # hoisted
if (!done)
return c & what; # wrong!
c = cpuid();
return c & what
This would lead to thread B using software AES even though AESNI was
available. This is a very minor performance bug. But also, given a very
powerful adversary who can block thread A indefinitely (which may be
possible when attacking an SGX enclave), thread B could use software AES for
a long time, opening the way to a timing side channel attack.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
I'm just trying to have a shorter name to avoid repeating a long
expression. This is a job for a pointer, not copying a struct.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This version is incomplete. I failed to noticed it when adding a more
complete version, making the existing one redundant.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
That memory leak had been present ever since the san command-line
argument has been added.
Tested that the following invocation is now fully valgrind clean:
programs/x509/cert_write san=DN:C=NL,CN=#0000,CN=foo;DN:CN=#0000,O=foo,OU=bar,C=UK;IP:1.2.3.4;IP:4.3.2.1;URI:http\\://example.org/;URI:foo;DNS:foo.example.org;DNS:bar.example.org
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The runtime error was introduced two commits ago (while avoiding a
use-after-free). Now the programs run cleanly but still leak memory.
The memory leak is long pre-existing and larger than just DN components
(which are made temporarily slightly worse by this commit) and will be
fixed properly in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The documentation doesn't say you can't call these functions more than
once on the same context, and if you do it shouldn't result in a memory
leak. Historically, the call to mbedtls_asn1_free_named_data_list() in
mbedtls_x509_string_to_names() (that was removed in the previous commit)
was ensuring that. Let's restore it where it makes sense. (These are the
only 3 places calling mbedtls_x509_string_to_names() in the library.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now programs/x509/cert_write san="DN:CN=#0000;DN:CN=#0000" is no longer
crashing with use-after-free, instead it's now failing cleanly:
failed
! mbedtls_x509_string_to_names returned -0x2800 - X509 - Input invalid
That's better of course but still not great, will be fixed by future
commits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This structure is initialized during the compilation and there is no
reason it changes.
Making it const allows the compiler to put it in .rodata section instead
of .data one.
Signed-off-by: Xavier Chapron <chapron.xavier@gmail.com>
Previously, the length of the label was limited to the maximal length
that would be used in the TLS 1.3 key schedule. With the keying material
exporter, labels of up to 249 bytes may be used.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The openssl version in the docker image doesn't support TLS 1.3, so we
can't run the test.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
