On Wed, Mar 02, 2016 at 02:26:18PM +0000, Mark Rutland wrote: > Functions which the compiler has instrumented for ASAN place poison on > the stack shadow upon entry and remove this poison prior to returning. > > In the case of cpuidle, CPUs exit the kernel a number of levels deep > in C code. Any instrumented functions on this critical path will leave > portions of the stack shadow poisoned. > > If CPUs lose context and return to the kernel via a cold path, we > restore a prior context saved in __cpu_suspend_enter are forgotten, and > we never remove the poison they placed in the stack shadow area by > functions calls between this and the actual exit of the kernel. > > Thus, (depending on stackframe layout) subsequent calls to instrumented > functions may hit this stale poison, resulting in (spurious) KASAN > splats to the console. > > To avoid this, clear any stale poison from the idle thread for a CPU > prior to bringing a CPU online. > > Signed-off-by: Mark Rutland <mark.rutland@xxxxxxx> > Cc: Alexander Potapenko <glider@xxxxxxxxxx> > Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> > Cc: Will Deacon <will.deacon@xxxxxxx> > --- > arch/arm64/kernel/sleep.S | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S > index e33fe33..fd10eb6 100644 > --- a/arch/arm64/kernel/sleep.S > +++ b/arch/arm64/kernel/sleep.S > @@ -145,6 +145,10 @@ ENTRY(cpu_resume_mmu) > ENDPROC(cpu_resume_mmu) > .popsection > cpu_resume_after_mmu: > +#ifdef CONFIG_KASAN > + mov x0, sp > + bl kasan_unpoison_remaining_stack > +#endif Lorenzo, as this was following your suggestion [1], I hope that this patch looks ok to you? Are you happy to provide an Ack / Reviewed-by? Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413061.html -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
