From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area)
Date: Wed, 17 Feb 2016 17:01:11 +0000 [thread overview]
Message-ID: <20160217170110.GE32647@leverpostej> (raw)
In-Reply-To: <20160217143950.GC32647@leverpostej>
On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
> When we go down for idle, in __cpu_suspend_enter we stash some context
> to the stack (in assembly). The CPU may return from a cold state via
> cpu_resume, where we restore context from the stack.
>
> However, after storing the context we call psci_suspend_finisher, which
> calls psci_cpu_suspend, which calls invoke_psci_fn_*. As
> psci_cpu_suspend and invoke_psci_fn_* are instrumented, they poison
> memory on function entrance, but we never perform the unpoisoning.
>
> That was always the case for psci_suspend_finisher, so there was a
> latent issue that we were somehow avoiding. Perhaps we got luck with
> stack layout and never hit the poison.
>
> I'm not sure how we fix that, as invoke_psci_fn_* may or may not return
> for arbitrary reasons (e.g. a CPU_SUSPEND_CALL may or may not return
> depending on whether an interrupt comes in at the right time).
>
> Perhaps the simplest option is to not instrument invoke_psci_fn_* and
> psci_suspend_finisher. Do we have a per-function annotation to avoid
> KASAN instrumentation, like notrace? I need to investigate, but we may
> also need notrace for similar reasons.
I found __no_sanitize_address.
As an aside, could we rename that to nokasan? That would match the style
of notrace, is just as clear, and would make it far easier to write
consistent legible function prototypes...
Otherwise, I came up with the patch below, per the reasoning above.
It _changes_ the KASAN splats (I see errors in tick_program_event rather
than find_busiest_group), but doesn't seem to get rid of them. I'm not
sure if I've missed something, or if we also have another latent issue.
Ideas?
Mark.
---->8----
>From 8f7ae44d8f8862f5300483d45617b5bd05fc652f Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 17 Feb 2016 15:38:22 +0000
Subject: [PATCH] arm64/psci: avoid KASAN splats with idle
When a CPU goes into a deep idle state, we store CPU context in
__cpu_suspend_enter, then call psci_suspend_finisher to invoke the
firmware. If we entered a deep idle state, we do not return directly,
and instead start cold, restoring state in cpu_resume.
Thus we may execute the prologue and body of psci_suspend_finisher and
the PSCI invocation function, but not their epilogue. When using KASAN
this means that we poison a region of shadow memory, but never unpoison
it. After we resume, subsequent stack accesses may hit the stale poison
values, leading to false positives from KASAN.
To avoid this, we must ensure that functions called after the context
save are not instrumented, and do not posion the shadow region, by
annotating them with __no_sanitize_address. As common inlines they may
call are not similarly annotated, and the compiler refuses to allow
function attribute mismatches, we must also avoid calls to such
functions.
ARM is not affected, as it does not support KASAN. When CONFIG_KASAN is
not selected, __no_sanitize_address expands to nothing, so the
annotation should not be harmful.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/kernel/psci.c | 14 ++++++++------
drivers/firmware/psci.c | 3 +++
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index f67f35b..8324ce8 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -32,12 +32,16 @@
static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
+static phys_addr_t cpu_resume_phys;
+
static int __maybe_unused cpu_psci_cpu_init_idle(unsigned int cpu)
{
int i, ret, count = 0;
u32 *psci_states;
struct device_node *state_node, *cpu_node;
+ cpu_resume_phys = virt_to_phys(cpu_resume);
+
cpu_node = of_get_cpu_node(cpu, NULL);
if (!cpu_node)
return -ENODEV;
@@ -178,12 +182,10 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
}
#endif
-static int psci_suspend_finisher(unsigned long index)
+__no_sanitize_address
+static int psci_suspend_finisher(unsigned long state)
{
- u32 *state = __this_cpu_read(psci_power_state);
-
- return psci_ops.cpu_suspend(state[index - 1],
- virt_to_phys(cpu_resume));
+ return psci_ops.cpu_suspend(state, cpu_resume_phys);
}
static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
@@ -200,7 +202,7 @@ static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
if (!psci_power_state_loses_context(state[index - 1]))
ret = psci_ops.cpu_suspend(state[index - 1], 0);
else
- ret = cpu_suspend(index, psci_suspend_finisher);
+ ret = cpu_suspend(state[index - 1], psci_suspend_finisher);
return ret;
}
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index f25cd79..e4e8dc1 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -106,6 +106,7 @@ bool psci_power_state_is_valid(u32 state)
return !(state & ~valid_mask);
}
+__no_sanitize_address
static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
unsigned long arg0, unsigned long arg1,
unsigned long arg2)
@@ -116,6 +117,7 @@ static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
return res.a0;
}
+__no_sanitize_address
static unsigned long __invoke_psci_fn_smc(unsigned long function_id,
unsigned long arg0, unsigned long arg1,
unsigned long arg2)
@@ -148,6 +150,7 @@ static u32 psci_get_version(void)
return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
}
+__no_sanitize_address
static int psci_cpu_suspend(u32 state, unsigned long entry_point)
{
int err;
--
1.9.1
next prev parent reply other threads:[~2016-02-17 17:01 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 10:54 [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 1/8] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings Ard Biesheuvel
2016-02-01 14:10 ` Mark Rutland
2016-02-01 14:56 ` Catalin Marinas
2016-02-01 10:54 ` [PATCH v5sub1 3/8] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 4/8] arm64: pgtable: implement static [pte|pmd|pud]_offset variants Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 5/8] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 6/8] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2016-02-01 12:24 ` Catalin Marinas
2016-02-01 12:27 ` Ard Biesheuvel
2016-02-01 13:41 ` Catalin Marinas
2016-02-01 14:32 ` Mark Rutland
2016-02-12 14:58 ` Catalin Marinas
2016-02-12 15:02 ` Ard Biesheuvel
2016-02-12 15:10 ` Catalin Marinas
2016-02-12 15:17 ` Ard Biesheuvel
2016-02-12 15:26 ` Catalin Marinas
2016-02-12 15:38 ` Sudeep Holla
2016-02-12 16:06 ` Catalin Marinas
2016-02-12 16:44 ` Ard Biesheuvel
2016-02-15 14:28 ` Andrey Ryabinin
2016-02-15 14:35 ` Mark Rutland
2016-02-15 18:59 ` Catalin Marinas
2016-02-16 12:59 ` Andrey Ryabinin
2016-02-16 14:12 ` Mark Rutland
2016-02-16 14:29 ` Mark Rutland
2016-02-16 15:17 ` Ard Biesheuvel
2016-02-16 15:36 ` Andrey Ryabinin
2016-02-16 16:42 ` Mark Rutland
2016-02-17 9:15 ` Andrey Ryabinin
2016-02-17 10:10 ` James Morse
2016-02-17 10:19 ` Catalin Marinas
2016-02-17 10:36 ` Catalin Marinas
2016-02-17 10:18 ` Catalin Marinas
2016-02-17 10:48 ` Mark Rutland
2016-02-17 14:39 ` Mark Rutland
2016-02-17 16:31 ` Andrey Ryabinin
2016-02-17 19:35 ` Mark Rutland
2016-02-17 17:01 ` Mark Rutland [this message]
2016-02-17 17:56 ` KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area) Mark Rutland
2016-02-17 19:16 ` Mark Rutland
2016-02-18 8:06 ` Ard Biesheuvel
2016-02-18 8:22 ` KASAN issues with idle / hotplug area Andrey Ryabinin
2016-02-18 8:42 ` Andrey Ryabinin
2016-02-18 9:38 ` Andrey Ryabinin
2016-02-18 11:34 ` Mark Rutland
2016-02-18 9:39 ` Lorenzo Pieralisi
2016-02-18 11:38 ` Mark Rutland
2016-02-18 11:45 ` Andrey Ryabinin
2016-02-18 11:15 ` Mark Rutland
2016-02-18 11:46 ` Andrey Ryabinin
2016-02-18 12:08 ` Mark Rutland
2016-02-12 17:47 ` [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area James Morse
2016-02-12 18:01 ` Ard Biesheuvel
2016-02-01 10:54 ` [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2016-02-01 14:50 ` Mark Rutland
2016-02-01 16:28 ` Fu Wei
2016-02-16 8:55 ` Fu Wei
2016-02-01 15:06 ` Catalin Marinas
2016-02-01 15:13 ` Ard Biesheuvel
2016-02-01 16:31 ` Ard Biesheuvel
2016-02-01 17:31 ` Catalin Marinas
2016-02-01 17:57 ` Ard Biesheuvel
2016-02-01 18:02 ` Catalin Marinas
2016-02-01 18:30 ` [PATCH] arm64: move back to generic memblock_enforce_memory_limit() Ard Biesheuvel
2016-02-02 10:19 ` Catalin Marinas
2016-02-02 10:28 ` Ard Biesheuvel
2016-02-02 10:44 ` Catalin Marinas
2016-02-12 19:45 ` [PATCH v5sub1 0/8] arm64: split linear and kernel mappings Matthias Brugger
2016-02-12 19:47 ` Ard Biesheuvel
2016-02-12 20:10 ` Matthias Brugger
2016-02-12 20:37 ` Ard Biesheuvel
2016-02-13 14:28 ` Ard Biesheuvel
2016-02-15 13:29 ` Matthias Brugger
2016-02-15 13:40 ` Will Deacon
2016-02-15 14:58 ` Ard Biesheuvel
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=20160217170110.GE32647@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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