PR is now available here: https://github.com/openssl/openssl/pull/17762 -Arran > On Feb 22, 2022, at 11:10 AM, Arran Cudbard-Bell <a.cudbardb@xxxxxxxxxxxxxx> wrote: > > In our application we use the OpenSSL ASYNC_* API to jump out of verification and session load/store callbacks. > > On the POSIX side, when creating a new context OpenSSL calls the standard OPENSSL_malloc and > OPENSSL_free functions to allocate memory for the stack passed into makecontext. > > https://github.com/openssl/openssl/blob/1c0eede9827b0962f1d752fa4ab5d436fa039da4/crypto/async/arch/async_posix.c > > There are several issues with this approach: > > 1. On some systems stack memory must be page aligned. The user provided allocation functions > don't know the context in which the memory is being requested so can't ensure this. > 2. glibc recommends the stack be allocated with mmap and set to executable to allow trampoline > functions to work correctly (unsure if this is relevant). > https://www.gnu.org/software/libc/manual/html_node/System-V-contexts.html > 3. Using heap memory for the stack means there's no guard page. Overflowing the stack appears > to cause silent memory corruption on both macOS and Linux. > > The stack size is also currently fixed and requires OpenSSL recompilation to change. > > I'd like to make the stack allocation and free functions configurable. > > Ideally the malloc function would have a signature similar to this: > > void *(*stack_alloc)(size_t *len); > > and free would be > > void (*stack_free)(void *stack); > > The idea being that the allocation function returns the memory it allocated for the stack, and the size of the stack via *len. > > If user stack alloc/free functions are not configured then we'd fall back to the standard OPENSSL_malloc() and OPENSSL_free() > functions with a static stack size. > > For our particular use case we're planning to have stack_alloc create a new thread. We'll then return the stack allocated > for that thread, which we believe in most cases fixes the issues described above. > > The free function will then signal/join the thread. > > -Arran > > > Arran Cudbard-Bell <a.cudbardb@xxxxxxxxxxxxxx> > FreeRADIUS Development Team > > FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 >
Attachment:
signature.asc
Description: Message signed with OpenPGP
