From: Mark Rutland <mark.rutland@arm.com>
To: linux-mm@kvack.org, mingo@redhat.com, akpm@linux-foundation.org
Cc: aryabinin@virtuozzo.com, catalin.marinas@arm.com,
glider@google.com, lorenzo.pieralisi@arm.com,
mark.rutland@arm.com, peterz@infradead.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel
Date: Thu, 3 Mar 2016 16:54:25 +0000 [thread overview]
Message-ID: <1457024068-2236-1-git-send-email-mark.rutland@arm.com> (raw)
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.
Since v1 [4]:
* Clean from task_stack_page(task)
* Add acks from v1
Andrew, the conclusion [5] from v1 was that this should go via the mm tree.
Are you happy to pick this up?
Ingo was happy for the sched patch to go via the arm64 tree, and I assume that
also holds for going via mm. Ingo, please shout if that's not the case!
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
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413093.html
[5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413475.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(-)
--
1.9.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: linux-mm@kvack.org, mingo@redhat.com, akpm@linux-foundation.org
Cc: aryabinin@virtuozzo.com, catalin.marinas@arm.com,
glider@google.com, lorenzo.pieralisi@arm.com,
mark.rutland@arm.com, peterz@infradead.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel
Date: Thu, 3 Mar 2016 16:54:25 +0000 [thread overview]
Message-ID: <1457024068-2236-1-git-send-email-mark.rutland@arm.com> (raw)
Message-ID: <20160303165425.iVHCIl72mAW1WaEPrtNJ5UdOlyrAGFIUC-CCBz2XmuQ@z> (raw)
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.
Since v1 [4]:
* Clean from task_stack_page(task)
* Add acks from v1
Andrew, the conclusion [5] from v1 was that this should go via the mm tree.
Are you happy to pick this up?
Ingo was happy for the sched patch to go via the arm64 tree, and I assume that
also holds for going via mm. Ingo, please shout if that's not the case!
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
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413093.html
[5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/413475.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(-)
--
1.9.1
next reply other threads:[~2016-03-03 16:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 16:54 Mark Rutland [this message]
2016-03-03 16:54 ` [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel Mark Rutland
2016-03-03 16:54 ` [PATCHv2 1/3] kasan: add functions to clear stack poison Mark Rutland
2016-03-03 16:54 ` Mark Rutland
2016-03-03 16:54 ` [PATCHv2 2/3] sched/kasan: remove stale KASAN poison after hotplug Mark Rutland
2016-03-03 16:54 ` Mark Rutland
2016-03-03 16:54 ` [PATCHv2 3/3] arm64: kasan: clear stale stack poison Mark Rutland
2016-03-03 16:54 ` Mark Rutland
2016-03-03 17:17 ` [PATCHv2 0/3] KASAN: clean stale poison upon cold re-entry to kernel Alexander Potapenko
2016-03-03 17:17 ` Alexander Potapenko
2016-03-03 17:40 ` Mark Rutland
2016-03-03 17:45 ` Alexander Potapenko
2016-03-03 18:17 ` Mark Rutland
2016-03-03 18:17 ` Mark Rutland
2016-03-04 22:34 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1457024068-2236-1-git-send-email-mark.rutland@arm.com \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=catalin.marinas@arm.com \
--cc=glider@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).