From: Mark Rutland <mark.rutland@arm.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: rostedt@goodmis.org, mingo@redhat.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, ryabinin.a.a@gmail.com,
surovegin@google.com, Catalin Marinas <catalin.marinas@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Alexander Potapenko <glider@google.com>,
Will Deacon <will.deacon@arm.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Masami Hiramatsu <mhiramat@kernel.org>,
x86@kernel.org, kasan-dev@googlegroups.com
Subject: Re: [PATCH v4] kprobes: unpoison stack in jprobe_return() for KASAN
Date: Fri, 14 Oct 2016 14:08:26 +0100 [thread overview]
Message-ID: <20161014130818.GA11804@leverpostej> (raw)
In-Reply-To: <1476446070-5297-1-git-send-email-dvyukov@google.com>
On Fri, Oct 14, 2016 at 01:54:30PM +0200, Dmitry Vyukov wrote:
> KASAN stack instrumentation poisons stack redzones on function entry
> and unpoisons them on function exit. If a function exits abnormally
> (e.g. with a longjmp like jprobe_return()), stack redzones are left
> poisoned. Later this leads to random KASAN false reports.
>
> Unpoison stack redzones in the frames we are going to jump over
> before doing actual longjmp in jprobe_return().
>
> Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
... judging by the kbuild test robot I spoke too soon, and should have
been more thorough. :/
> +/*
> + * Clear all poison for the region between the current SP and a provided
> + * watermark value, as is sometimes required prior to hand-crafted asm function
> + * returns in the middle of functions.
> + */
> +void kasan_unpoison_stack_above_sp_to(const void *watermark)
> +{
> + const void *sp = (void *)current_stack_pointer();
Aargh; it seems current_stack_pointer() is only function-like on some
arches, and not on others (arm64 included). I should have known better;
sorry for the bad suggestion.
I'm not overjoyed about taking the address of a stack variable to
implement this ourselves. Can we use __builtin_frame_address(0) instead?
Or are there cases where that won't work on x86?
> + size_t size = watermark - sp;
> +
> + if (WARN_ON(sp > watermark))
> + return;
... not a new problem, but we should also include <linux/bug.h> for
WARN_ON().
Thanks,
Mark.
next prev parent reply other threads:[~2016-10-14 13:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-14 11:54 [PATCH v4] kprobes: unpoison stack in jprobe_return() for KASAN Dmitry Vyukov
2016-10-14 13:08 ` Mark Rutland [this message]
2016-10-14 14:08 ` Dmitry Vyukov
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=20161014130818.GA11804@leverpostej \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=ryabinin.a.a@gmail.com \
--cc=surovegin@google.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.