| Age | Commit message (Collapse) | Author |
|---|
|
This commit destroys the free list pointers which would otherwise be
present in the returned memory blocks. This in turn helps prevent
information leakage from the secure memory area.
Note: CRYPTO_secure_malloc is not guaranteed to return zeroed memory:
before the secure memory system is initialised or if it isn't implemented.
[manual merge of #7011]
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7026)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5493)
(cherry picked from commit 014cc4b27a7f8ed0cf23a3c9d1fdbf44e41b7993)
|
|
Even though mlock(2) was standardized in POSIX.1-2001, vendors did
implement it prior that point.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5460)
(cherry picked from commit 5839185cdd9b339ff741da437d964a25e72a3fb6)
|
|
./config -DOPENSSL_NO_SECURE_MEMORY
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5113)
(cherry picked from commit 154d8c132fbe22a248f95e95ef21f1840451da62)
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5060)
(cherry picked from commit e44c7d02ddac975ec6abff7901e77a0c37f9949d)
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4876)
|
|
Use OPENSSL_secure_clear_free for secure mem BIOs
and X25519 private keys.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4048)
|
|
Remove assertion when mmap() fails.
Only give the 1<<31 limit test as an example.
Fix the small arena test to just check for the symptom of the infinite
loop (i.e. initialized set on failure), rather than the actual infinite
loop. This avoids some valgrind errors.
Backport of:
PR #3512 commit fee423bb68869de02fceaceefbc847e98213574b
PR #3510 commit a486561b691d6293a901b412172ca0c6d1ffc0dc
PR #3455 commit c8e89d58a5d44b9dd657d6d13a5a10d1d4d30733
PR #3449 commit 7031ddac94d0ae616d1b0670263a9265ce672cd2
Issue 1:
sh.bittable_size is a size_t but i is and int, which can result in
freelist == -1 if sh.bittable_size exceeds an int.
This seems to result in an OPENSSL_assert due to invalid allocation
size, so maybe that is "ok."
Worse, if sh.bittable_size is exactly 1<<31, then this becomes an
infinite loop (because 1<<31 is a negative int, so it can be shifted
right forever and sticks at -1).
Issue 2:
CRYPTO_secure_malloc_init() sets secure_mem_initialized=1 even when
sh_init() returns 0.
If sh_init() fails, we end up with secure_mem_initialized=1 but
sh.minsize=0. If you then call secure_malloc(), which then calls,
sh_malloc(), this then enters an infite loop since 0 << anything will
never be larger than size.
Issue 3:
That same sh_malloc loop will loop forever for a size greater
than size_t/2 because i will proceed (assuming sh.minsize=16):
i=16, 32, 64, ..., size_t/8, size_t/4, size_t/2, 0, 0, 0, 0, ....
This sequence will never be larger than "size".
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3453)
|
|
The sh_add_to_list function will overwrite subsequent slots in the free list
for small allocations. This causes a segmentation fault if the writes goes
off the end of the secure memory. I've not investigated if this problem
can overwrite memory without the segmentation fault, but it seems likely.
This fix limits the minsize to the sizeof of the SH_LIST structure (which
also has a side effect of properly aligning the pointers).
The alternative would be to return an error if minsize is too small.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2657)
(cherry picked from commit 70e14ffbaf6a67dab56c24cae01f1248cf3f1e77)
|
|
which are not possible with the default OPENSSL_zalloc, but are possible if
the user has installed their own allocator using CRYPTO_set_mem_functions. If
the 0-allocations succeeds, the secure heap code will later access
(at least) the first byte of that space, which is technically an OOB
access. This could lead to problems with some custom allocators that only
return a valid pointer for subsequent free()-ing, and do not expect that
the pointer is actually dereferenced.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2605)
(cherry picked from commit 7f07149d25f8d7e00e9350ff2f064a4d25c1a13d)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Document thread-safe lock creation
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Fix some of the variables to be (s)size_t, so that more than 1GB of
secure memory can be allocated. The arena has to be a power of 2, and
2GB fails because it ends up being a negative 32-bit signed number.
The |too_late| flag is not strictly necessary; it is easy to figure
out if something is secure memory by looking at the arena. As before,
secure memory allocations will not fail, but now they can be freed
correctly. Once initialized, secure memory can still be used, even if
allocations occured before initialization.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Use new Thread API style locks, and thread local storage for mem_dbg
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Commit 05c7b1631 ("Implement the use of heap manipulator implementions")
added 'file' and 'line' arguments to CRYPTO_free() and friends, but neglected
to fix up the !IMPLEMENTED case within CRYPTO_secure_free(). Add the missing
arguments there too.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
- Make use of the functions given through CRYPTO_set_mem_functions().
- CRYPTO_free(), CRYPTO_clear_free() and CRYPTO_secure_free() now receive
__FILE__ and __LINE__.
- The API for CRYPTO_set_mem_functions() and CRYPTO_get_mem_functions()
is slightly changed, the implementation for free() now takes a couple
of extra arguments, taking __FILE__ and __LINE__.
- The CRYPTO_ memory functions will *always* receive __FILE__ and __LINE__
from the corresponding OPENSSL_ macros, regardless of if crypto-mdebug
has been enabled or not. The reason is that if someone swaps out the
malloc(), realloc() and free() implementations, we can't know if they
will use them or not.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
memset() is used by CRYPTO_secure_zalloc(), which isn't hidden away
behind IMPLEMENTED.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Also turn B<foo> into foo() in the pod page.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
|
|
This is already documented, I just forgot to include the code :)
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
|
|
Only two macros CRYPTO_MDEBUG and CRYPTO_MDEBUG_ABORT to control this.
If CRYPTO_MDEBUG is not set, #ifdef out the whole debug machinery.
(Thanks to Jakob Bohm for the suggestion!)
Make the "change wrapper functions" be the only paradigm.
Wrote documentation!
Format the 'set func' functions so their paramlists are legible.
Format some multi-line comments.
Remove ability to get/set the "memory debug" functions at runtme.
Remove MemCheck_* and CRYPTO_malloc_debug_init macros.
Add CRYPTO_mem_debug(int flag) function.
Add test/memleaktest.
Rename CRYPTO_malloc_init to OPENSSL_malloc_init; remove needless calls.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
We've been using int for the size for a long time, it's about time...
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
