Closed skdeep2001 closed 2 years ago
Related to: https://github.com/awslabs/s2n/issues/772
See my PR for a go at this. I ended up implementing it a little differently in practice, because I have to work around the mlock / advise but I think I came up with a clean way to do it all.
See my PR for a go at this. I ended up implementing it a little differently in practice, because I have to work around the mlock / advise but I think I came up with a clean way to do it all.
This will be very useful ! Tested with mock server client for my application that requires this.
Addressed in PR#1763
Problem:
s2n today uses its own memory management routines for allocating memory. This is not ideal and/or breaks for uses cases that have very specific memory management requirements especially in a multi-threaded and/or multi-socket and/or some embedded environments.
Proposed Solution:
1) s2n API exposes a new structure of callbacks:
2) Provide a default allocator that implements the current functionality:
s2n_mem.h
s2n_mem.c
3) Existing s2n_mem APIs need to be modified to accept an s2n_allocator*.
4) New APIs for applications that need user defined memory management. These will pass in the allocator to all the underlying calls such as s2n_alloc, s2n_realloc, s2n_free etc. The s2n_config, s2n_connection, s2n_cert_chain_and_key structures will also have a pointer to the allocator so that it can be used by its associated functions and the corresponding *_free() functions.
s2n.h
5) Existing APIs modified to use the default allocator:
For example
Risks: 1) One of the risks is that this requires modifying lots of internal interfaces and propagating the allocators through the codebase. 2) Doesn't address any allocations done by the underlying OpenSSL calls.
Benefits: 1) Allocators can be instrumented to tally allocs vs frees. 2) User can customize the allocation strategy fo multi-thread, multi-socket or even finer granularity.