Re: randomize_kstack: To init or not to init?

Jann Horn
2021-12-09T21:16:45Z

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?