All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vince Weaver <vincent.weaver@maine.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Vince Weaver <vincent.weaver@maine.edu>,
	Peter Zijlstra <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	"davej@codemonkey.org.uk" <davej@codemonkey.org.uk>,
	Stephane Eranian <eranian@gmail.com>
Subject: Re: perf: fuzzer KASAN unwind_get_return_address
Date: Thu, 17 Nov 2016 12:15:54 -0500 (EST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611171213310.11652@macbook-air> (raw)
In-Reply-To: <CACT4Y+ZRCnnB0G=eF-oCqZQ1EiCgFTCdYXdbM07ZztHcqFnoLA@mail.gmail.com>

On Thu, 17 Nov 2016, Dmitry Vyukov wrote:

> On Thu, Nov 17, 2016 at 3:36 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > On Thu, Nov 17, 2016 at 09:25:58AM -0500, Vince Weaver wrote:
> >> On Thu, 17 Nov 2016, Josh Poimboeuf wrote:
> >>
> >> > On Thu, Nov 17, 2016 at 10:48:27AM +0100, Dmitry Vyukov wrote:
> >> > > Just in case, there is currently a known KASAN false positive related
> >> > > to longjmp's on GPFs. When a syscall hits GPF stack is unwound to
> >> > > kernel entry point, this leaves a bunch of stray poisoned redzones on
> >> > > the thread stack. They later cause false stack-out-of-bounds reports.
> >> > >
> >> > > But this does not seem to be the case here. Kernel is not tainted. And
> >> > > shadow at the bottom of the reports looks sane.
> >> > >
> >> > > But if that's the case somehow, we will need to add
> >> > > kasan_unpoison_remaining_stack() call before a longjmp like we did for
> >> > > jprobe_return():
> >> > > https://groups.google.com/d/msg/kasan-dev/Hzox58yZ4MU/TOdFoWMuBQAJ
> >> >
> >> > I'm pretty sure this isn't a KASAN false positive.  The unwinder does
> >> > actually seem to be accessing a bad area of the stack, in the middle of
> >> > a function's stack frame.
> >>
> >> I'm having trouble reproducing it on a few other machines I have fuzzing.
> >> So there might be some kernel option contributing, I need to compare
> >> .configs.
> >>
> >> Also the machine that easily triggers the problem I'm compiling with
> >> gcc-5.4 where the machines I can't are using gcc-4.9.
> >
> > I believe KASAN only works with gcc 5 and later, so that would explain
> > why you aren't seeing it with gcc 4.9.
> 
> Right. 4.9 has limited support for KASAN. It supports general
> instrumentation, but only with CONFIG_KASAN_OUTLINE, and it does not
> support stack poisoning. Which is required to detect stack OOBs.

I guess it's time to update the other machines to debian-unstable then.  I 
didn't really need to be able to run dmesg as non-root anyway.

I would actually be compiling the kernels with gcc-6.2 rather than gcc-5 
but that seems to not work currently.  Haven't had time to see if that's a 
known issue or not.

Vince

  reply	other threads:[~2016-11-17 17:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 17:43 perf: fuzzer KASAN unwind_get_return_address Vince Weaver
2016-11-15 18:57 ` Peter Zijlstra
2016-11-15 19:04   ` Dmitry Vyukov
2016-11-15 20:56     ` Josh Poimboeuf
2016-11-15 19:05   ` Vince Weaver
2016-11-15 20:57     ` Josh Poimboeuf
2016-11-16 13:03       ` Peter Zijlstra
2016-11-16 13:18         ` Dmitry Vyukov
2016-11-16 14:37         ` Josh Poimboeuf
2016-11-16 14:49           ` Peter Zijlstra
2016-11-16 14:58             ` Josh Poimboeuf
2016-11-16 14:58             ` Peter Zijlstra
2016-11-17  4:48               ` Josh Poimboeuf
2016-11-17  9:04                 ` Peter Zijlstra
2016-11-17  9:13                   ` Peter Zijlstra
2016-11-17  9:30                     ` Peter Zijlstra
2016-11-17  9:48                       ` Dmitry Vyukov
2016-11-17 14:01                         ` Josh Poimboeuf
2016-11-17 14:25                           ` Vince Weaver
2016-11-17 14:36                             ` Josh Poimboeuf
2016-11-17 14:58                               ` Dmitry Vyukov
2016-11-17 17:15                                 ` Vince Weaver [this message]
2016-11-17 15:18                   ` Josh Poimboeuf
2016-11-17 16:07                     ` Peter Zijlstra
2016-11-17 17:17                       ` Peter Zijlstra
2016-11-22 12:30                         ` [tip:perf/urgent] perf/x86/intel: Cure bogus unwind from PEBS entries tip-bot for Peter Zijlstra
2016-11-16 15:06             ` perf: fuzzer KASAN unwind_get_return_address Vince Weaver
2016-11-17 15:57         ` [PATCH 1/2] unwind: prevent KASAN false positive warnings in guess unwinder Josh Poimboeuf
2016-11-17 15:57           ` [PATCH 2/2] dumpstack: prevent KASAN false positive warnings Josh Poimboeuf
2016-11-18  9:04             ` [tip:x86/urgent] x86/dumpstack: Prevent " tip-bot for Josh Poimboeuf
2016-11-17 20:26           ` [PATCH 1/2] unwind: prevent KASAN false positive warnings in guess unwinder Josh Poimboeuf
2016-11-18  8:38             ` Ingo Molnar
2016-11-18  9:04           ` [tip:x86/urgent] x86/unwind: Prevent " tip-bot for Josh Poimboeuf

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=alpine.DEB.2.20.1611171213310.11652@macbook-air \
    --to=vincent.weaver@maine.edu \
    --cc=acme@kernel.org \
    --cc=davej@codemonkey.org.uk \
    --cc=dvyukov@google.com \
    --cc=eranian@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@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 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.