Commit graph

28 commits

Author SHA1 Message Date
Bernd Edlinger
154d8c132f Add a configure option to opt-out secure memory
./config -DOPENSSL_NO_SECURE_MEMORY

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5113)
2018-01-21 16:08:30 +01:00
Richard Levitte
48e5119a6b Copyright update of more files that have changed this year
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5110)
2018-01-19 13:34:03 +01:00
Richard Levitte
e44c7d02dd Only implement secure malloc if _POSIX_VERSION allows
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5060)
2018-01-18 14:05:33 +01:00
Rich Salz
cbe2964821 Consistent formatting for sizeof(foo)
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4872)
2017-12-07 19:11:49 -05:00
Rich Salz
ed6b2c7938 Add CRYPTO_thread_glock_new
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4294)
2017-08-31 19:42:03 -04:00
Pauli
07016a8a31 Move e_os.h to be the very first include.
cryptilib.h is the second.

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4188)
2017-08-30 07:20:44 +10:00
Rich Salz
bef7a81530 Use "" not <> on e_os.h include
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4220)
2017-08-22 11:07:56 -04:00
Bernd Edlinger
4dae7cd3f0 Implement the CRYPTO_secure_clear_free function
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4044)
2017-07-29 19:26:06 +02:00
Rich Salz
624265c60e Cleanup some copyright stuff
Remove some incorrect copyright references.
Move copyright to standard place
Add OpenSSL copyright where missing.
Remove copyrighted file that we don't use any more
Remove Itanium assembler for RC4 and MD5 (assembler versions of old and
weak algorithms for an old chip)
Standardize apps/rehash copyright comment; approved by Timo
Put dual-copyright notice on mkcert

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3691)
2017-06-30 21:56:44 -04:00
Todd Short
c8e89d58a5 Tweak sec_mem tests
Remove assertion when mmap() fails.
Only run the 1<<31 limit test on Linux

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3455)
2017-05-20 20:54:04 -04:00
Todd Short
7031ddac94 Fix infinite loops in secure memory allocation.
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3449)
2017-05-11 22:35:21 +02:00
Todd Short
9dfc5b9687 Add support for MLOCK_ONFAULT to secure arena
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3115)
2017-04-06 12:53:23 +02:00
Rich Salz
332dc4fa5e sh_malloc & sh_free prototype change to match POSIX
CLA: trivial

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2823)
2017-03-02 19:16:57 -05:00
Pauli
70e14ffbaf Ensure minsize >= sizeof(SH_LIST)
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)
2017-02-21 09:44:50 -05:00
Guido Vranken
7f07149d25 Prevent allocations of size 0 in sh_init, 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)
2017-02-14 14:28:34 -05:00
Rich Salz
4f22f40507 Copyright consolidation 06/10
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-17 14:51:04 -04:00
Viktor Dukhovni
5c4328f04f Fold threads.h into crypto.h making API public
Document thread-safe lock creation

Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-16 12:16:26 -04:00
Todd Short
e8408681b3 Secure memory fixes
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>
2016-05-02 12:58:03 -04:00
Matt Caswell
9471f7760d Convert mem_dbg and mem_sec to the new Thread API
Use new Thread API style locks, and thread local storage for mem_dbg

Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-08 21:06:04 +00:00
Rich Salz
a773b52a61 Remove unused parameters from internal functions
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-22 13:39:44 -05:00
David Woodhouse
6a78ae2821 RT4313: Fix build for !IMPLEMENTED code path in CRYPTO_secure_free()
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>
2016-02-17 09:16:01 -05:00
Richard Levitte
05c7b1631b Implement the use of heap manipulator implementions
- 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>
2016-02-17 10:12:49 +01:00
Richard Levitte
183733f882 Make sure to always include string.h so memset gets declared.
memset() is used by CRYPTO_secure_zalloc(), which isn't hidden away
behind IMPLEMENTED.

Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10 04:14:35 +01:00
Rich Salz
3538c7da3d Add CRYPTO_secure_zalloc
Also turn B<foo> into foo() in the pod page.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-27 23:34:13 -05:00
Rich Salz
d594199bb4 RT41897: Add an CRYPTO_secure_actual_size
This is already documented, I just forgot to include the code :)

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-01-09 19:13:15 -05:00
Rich Salz
bbd86bf542 mem functions cleanup
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>
2016-01-07 15:14:18 -05:00
Richard Levitte
ff8428561a Modify the lower level memory allocation routines to take size_t
We've been using int for the size for a long time, it's about time...

Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-17 08:24:26 +01:00
Rich Salz
3b089ca21b Rename sec_mem to mem_sec, like other files.
Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-12-16 22:09:39 -05:00
Renamed from crypto/sec_mem.c (Browse further)