[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190225145240.GB32534@hirez.programming.kicks-ass.net>
Date: Mon, 25 Feb 2019 15:52:40 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
stable <stable@...r.kernel.org>,
Changbin Du <changbin.du@...il.com>,
Jann Horn <jannh@...gle.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access
kernel memory that can fault
On Mon, Feb 25, 2019 at 09:33:09AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 24, 2019 at 09:26:45AM -0800, Linus Torvalds wrote:
> > PeterZ, do you remember the particular use case that triggered that
> > commit 7c4788950ba5 ("x86/uaccess, sched/preempt: Verify access_ok()
> > context")?
>
> This one, if I'm not mistaken.
>
> ---
>
> commit ae31fe51a3cceaa0cabdb3058f69669ecb47f12e
> Author: Johannes Weiner <hannes@...xchg.org>
> Date: Tue Nov 22 10:57:42 2016 +0100
>
> perf/x86: Restore TASK_SIZE check on frame pointer
>
> The following commit:
>
> 75925e1ad7f5 ("perf/x86: Optimize stack walk user accesses")
>
> ... switched from copy_from_user_nmi() to __copy_from_user_nmi() with a manual
> access_ok() check.
>
> Unfortunately, copy_from_user_nmi() does an explicit check against TASK_SIZE,
> whereas the access_ok() uses whatever the current address limit of the task is.
>
> We are getting NMIs when __probe_kernel_read() has switched to KERNEL_DS, and
> then see vmalloc faults when we access what looks like pointers into vmalloc
> space:
Also note that this was before we did:
commit 88b0193d9418c00340e45e0a913a0813bc6c8c96
Author: Will Deacon <will.deacon@....com>
Date: Tue May 9 18:00:04 2017 +0100
perf/callchain: Force USER_DS when invoking perf_callchain_user()
Perf can generate and record a user callchain in response to a synchronous
request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS),
then we can end up walking the user stack (and dereferencing/saving whatever we
find there) without the protections usually afforded by checks such as
access_ok.
Rather than play whack-a-mole with each architecture's stack unwinding
implementation, fix the root of the problem by ensuring that we force USER_DS
when invoking perf_callchain_user from the perf core.
Reported-by: Al Viro <viro@...IV.linux.org.uk>
Signed-off-by: Will Deacon <will.deacon@....com>
Acked-by: Peter Zijlstra <peterz@...radead.org>
Cc: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Jiri Olsa <jolsa@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c04917cad1bf..1b2be63c8528 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -229,12 +229,18 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool kernel, bool user,
}
if (regs) {
+ mm_segment_t fs;
+
if (crosstask)
goto exit_put;
if (add_mark)
perf_callchain_store_context(&ctx, PERF_CONTEXT_USER);
+
+ fs = get_fs();
+ set_fs(USER_DS);
perf_callchain_user(&ctx, regs);
+ set_fs(fs);
}
}
Powered by blists - more mailing lists