On 04.06.2020 17:01, Jann Horn wrote: > On Thu, Jun 4, 2020 at 3:51 PM Alexander Popov <alex.popov@xxxxxxxxx> wrote: >> Some time ago Variable Length Arrays (VLA) were removed from the kernel. >> The kernel is built with '-Wvla'. Let's exclude alloca() from the >> instrumentation logic and make it simpler. The build-time assertion >> against alloca() is added instead. > [...] >> + /* Variable Length Arrays are forbidden in the kernel */ >> + gcc_assert(!is_alloca(stmt)); > > There is a patch series from Elena and Kees on the kernel-hardening > list that deliberately uses __builtin_alloca() in the syscall entry > path to randomize the stack pointer per-syscall - see > <https://lore.kernel.org/kernel-hardening/20200406231606.37619-4-keescook@xxxxxxxxxxxx/>. Thanks, Jann. At first glance, leaving alloca() handling in stackleak instrumentation logic would allow to integrate stackleak and this version of random_kstack_offset. Kees, Elena, did you try random_kstack_offset with upstream stackleak? It looks to me that without stackleak erasing random_kstack_offset can be weaker. I mean, if next syscall has a bigger stack randomization gap, the data on thread stack from the previous syscall is not overwritten and can be used. Am I right? Another aspect: CONFIG_STACKLEAK_METRICS can be used for guessing kernel stack offset, which is bad. It should be disabled if random_kstack_offset is on. Best regards, Alexander
