linux-kernel - Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2016 12:38:09 +0000
From:	Mark Rutland <mark.rutland@....com>
To:	Ingo Molnar <mingo@...nel.org>, akpm@...ux-foundation.org,
	aryabinin@...tuozzo.com, catalin.marinas@....com
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, glider@...gle.com,
	lorenzo.pieralisi@....com, mingo@...hat.com, peterz@...radead.org,
	will.deacon@....com
Subject: Re: [PATCH 0/3] KASAN: clean stale poison upon cold re-entry to
 kernel

On Thu, Mar 03, 2016 at 01:02:27PM +0100, Ingo Molnar wrote:
> 
> * Mark Rutland <mark.rutland@....com> 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 some cases (e.g. hotplug and idle), CPUs may exit the kernel a number
> > of levels deep in C code. If there are any instrumented functions on
> > this critical path, these will leave portions of the idle thread stack
> > shadow poisoned.
> > 
> > If a CPU returns to the kernel via a different path (e.g. a cold entry),
> > then depending on stack frame layout subsequent calls to instrumented
> > functions may use regions of the stack with stale poison, resulting in
> > (spurious) KASAN splats to the console.
> > 
> > Contemporary GCCs always add stack shadow poisoning when ASAN is
> > enabled, even when asked to not instrument a function [1], so we can't
> > simply annotate functions on the critical path to avoid poisoning.
> > 
> > Instead, this series explicitly removes any stale poison before it can
> > be hit. In the common hotplug case we clear the entire stack shadow in
> > common code, before a CPU is brought online.
> > 
> > On architectures which perform a cold return as part of cpu idle may
> > retain an architecture-specific amount of stack contents. To retain the
> > poison for this retained context, the arch code must call the core KASAN
> > code, passing a "watermark" stack pointer value beyond which shadow will
> > be cleared. Architectures which don't perform a cold return as part of
> > idle do not need any additional code.
> > 
> > This is a combination of previous approaches [2,3], attempting to keep
> > as much as possible generic.
> > 
> > Thanks,
> > Mark.
> > 
> > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863
> > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409466.html
> > [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/411850.html
> > 
> > Mark Rutland (3):
> >   kasan: add functions to clear stack poison
> >   sched/kasan: remove stale KASAN poison after hotplug
> >   arm64: kasan: clear stale stack poison
> > 
> >  arch/arm64/kernel/sleep.S |  4 ++++
> >  include/linux/kasan.h     |  6 +++++-
> >  kernel/sched/core.c       |  3 +++
> >  mm/kasan/kasan.c          | 20 ++++++++++++++++++++
> >  4 files changed, 32 insertions(+), 1 deletion(-)
> 
> Looks good to me - via which tree would you like to see this merged upstream?

I'd prefer the arm64 tree as arm64 is (the most) affected by the issue
in practice.

I'm happy for this to go via another tree if that's simpler; I'm not
aware of anything that's likely to conflict in the arm64 tree.

Catalin, Andrey, Andrew, any preference?

Thanks,
Mark.