Date: Mon, 5 Nov 2018 11:42:29 +0100 From: Ard Biesheuvel <ard.biesheuvel@...aro.org> To: Nicolas Pitre <nicolas.pitre@...aro.org> Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, Russell King - ARM Linux <linux@...linux.org.uk>, Kees Cook <keescook@...omium.org>, Arnd Bergmann <arnd@...db.de>, Emese Revfy <re.emese@...il.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Laura Abbott <labbott@...hat.com>, Marc Zyngier <marc.zyngier@....com> Subject: Re: [RFC/RFT PATCH] ARM: smp: add support for per-task stack canaries On 4 November 2018 at 21:36, Nicolas Pitre <nicolas.pitre@...aro.org> wrote: > On Sun, 4 Nov 2018, Ard Biesheuvel wrote: > >> On ARM, we currently only change the value of the stack canary when >> switching tasks if the kernel was built for UP. On SMP kernels, this >> is impossible since the stack canary value is obtained via a global >> symbol reference, which means >> a) all running tasks on all CPUs must use the same value >> b) we can only modify the value when no kernel stack frames are live, >> which is effectively never. >> >> So instead, use a GCC plugin to add a RTL pass that replaces each >> reference to the address of the __stack_chk_guard symbol with an >> expression that produces the address of the 'stack_canary' field >> that is added to struct thread_info. This way, each task will use >> its own randomized value. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org> >> --- >> Known issues: >> - The plugin requires the values of THREAD_SIZE and the offset of >> stack_canary in struct thread_info at a really early stage in the >> build, so I had to redefine them in the plugin source. > > Can't you rely on the asm-offsets.c mechanism before the plugin is used? > Not currently, no. The plugins are built with the host compiler before the target compiler is invoked, and asm-offsets is built with the target compiler. Kees: any ideas on how to resolve this? >> Questions: >> - Are there any execution contexts except for the decompressor and the >> EFI stub where we should disable this? KVM perhaps? > > Most certainly head-inflate-data.c... who knows if someone will use an > XIP kernel on an SMP system someday. > That is a bit tricky, unfortunately: building head-inflate-data.c with the stack protector disabled is easy, but we'll also need to build zlib_inflate() in the same way. > [...] >> +#ifdef CONFIG_STACKPROTECTOR_PER_TASK >> + BUILD_BUG_ON(offsetof(struct thread_info, stack_canary) != 100); >> + BUILD_BUG_ON(THREAD_SIZE != 0x2000); > > You should at least define those values in a header file that gets > included by both this code and the plugin source. But asm-offsets.c > would be best. > Sure. I will put the right hand sides in a shared header as #defines and use those in the plugin source.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.