Messages in this thread | | | From | Jann Horn <> | Date | Thu, 9 Dec 2021 22:16:16 +0100 | Subject | Re: randomize_kstack: To init or not to init? |
| |
On Thu, Dec 9, 2021 at 10:58 AM Marco Elver <elver@google.com> wrote: > Clang supports CONFIG_INIT_STACK_ALL_ZERO, which appears to be the > default since dcb7c0b9461c2, which is why this came on my radar. And > Clang also performs auto-init of allocas when auto-init is on > (https://reviews.llvm.org/D60548), with no way to skip. As far as I'm > aware, GCC 12's upcoming -ftrivial-auto-var-init= doesn't yet auto-init > allocas. > > add_random_kstack_offset() uses __builtin_alloca() to add a stack > offset. This means, when CONFIG_INIT_STACK_ALL_{ZERO,PATTERN} is > enabled, add_random_kstack_offset() will auto-init that unused portion > of the stack used to add an offset. > > There are several problems with this: > > 1. These offsets can be as large as 1023 bytes. Performing > memset() on them isn't exactly cheap, and this is done on > every syscall entry. > > 2. Architectures adding add_random_kstack_offset() to syscall > entry implemented in C require them to be 'noinstr' (e.g. see > x86 and s390). The potential problem here is that a call to > memset may occur, which is not noinstr.
This doesn't just affect alloca(), right? According to godbolt.org (https://godbolt.org/z/jYrWEx7o8):
void bar(char *p); void foo() { char arr[512]; bar(arr); }
when compiled with "-ftrivial-auto-var-init=pattern -O2 -mno-sse" gives this result:
foo: # @foo push rbx sub rsp, 512 mov rbx, rsp mov edx, 512 mov rdi, rbx mov esi, 170 call memset@PLT mov rdi, rbx call bar add rsp, 512 pop rbx ret
So I think to fix this properly in a way that doesn't conflict with noinstr validation, I think you'll have to add a compiler flag that lets you specify a noinstr-safe replacement for memset() that should be used here?
| |