Re: Custom secure heap implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




We would consider a patch of this nature.  There are plenty of platforms where we don’t know and don’t support secure memory.  Having customisable hooks would allow them secure memory too.


Yes, is *must* be thread safe — just like the existing implementation.


The malloc and free are the important calls.  I’m not sure the size and allocated calls are used widely (but it’s worth a check).
Secure memory *always* cleanses currently and I don’t see that changing — if something is important enough to put in secure memory, it’s important enough to zero on free.


Pauli

-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



On 5 May 2019, at 11:15 pm, Tobias Nießen <tniessen@xxxxxxx> wrote:

Hello,

I have been experimenting with a custom secure heap implementation recently. Would OpenSSL be open to a patch that allows users to replace the OpenSSL implementation with their own, similarly to how CRYPTO_set_mem_functions works? Based on mem_sec.c, at least sh_malloc, sh_free, sh_actual_size and sh_allocated need to be pluggable, probably also a new function for CRYPTO_secure_used.

Also, should thread safety be part of OpenSSL as it is right now (via sec_malloc_lock), or should it be up to the implementation?

Regards,
Tobias



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux