From: Dave Jones <davej@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Sasha Levin <sasha.levin@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] improve_stack: make stack dump output useful again
Date: Fri, 14 Mar 2014 15:08:24 -0400 [thread overview]
Message-ID: <20140314190824.GA6426@redhat.com> (raw)
In-Reply-To: <CAGXu5jLE6WHCwZVcMSUwQAa3=DW1LsxGd_1aGo8SzLpk8jC-xA@mail.gmail.com>
On Fri, Mar 14, 2014 at 11:31:11AM -0700, Kees Cook wrote:
> On Thu, Mar 13, 2014 at 4:12 PM, Dave Jones <davej@redhat.com> wrote:
> > On Thu, Mar 13, 2014 at 03:03:41PM -0700, Linus Torvalds wrote:
> >
> > > You need to look at the *symbol* number. In this output:
> > >
> > > [<ffffffff810020c2>] do_one_initcall+0xc2/0x1e0
> > >
> > > that "ffffffff810020c2" is crap, and is going away. The address that
> > > is meaningful and valid is the "do_one_initcall+0xc2" part.
> > >
> > > *That* is the part you'd use to parse in user space.
> > >
> > > Try it today with the CONFIG_RANDOMIZE_BASE option to see. Using the
> > > hex number doesn't *work*.
> >
> > That reminds me, perf top is still busted when this option is enabled.
>
> Hrm, works for me. I'm not very familiar with what to expect, but
> comparing output between kaslr boot and nokaslr boot, it looks the
> same to me.
ok, nokalsr makes it work too.
Booting with that and using the perf binary from 3.14rc6 , I just see..
9.30% [kernel] [k] 0xffffffffaf18e887
7.98% [kernel] [k] 0xffffffffaf3276c7
6.10% [kernel] [k] 0xffffffffaf18dd3a
4.39% [kernel] [k] 0xffffffffaf327717
1.71% [kernel] [k] 0xffffffffaf18e89c
1.52% [kernel] [k] 0xffffffffaf3276cc
Curiously, if I use the perf binary from 3.13, I see everything lumped together as..
95.89% [kernel].exit.text [k] 0x000000002e586c26
(When kaslr is disabled both binaries work fine)
Also maybe related: The rc6 binary claims it can't read symbols from vmlinux
when kaslr is enabled.
Dave
next prev parent reply other threads:[~2014-03-14 19:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-23 0:19 [RFC] improve_stack: make stack dump output useful again Sasha Levin
2014-02-23 20:27 ` Linus Torvalds
2014-02-23 20:44 ` Joe Perches
2014-02-23 20:55 ` Linus Torvalds
2014-03-13 15:16 ` Sasha Levin
2014-03-13 22:03 ` Linus Torvalds
2014-03-13 22:20 ` Sasha Levin
2014-03-13 22:59 ` Linus Torvalds
2014-03-13 23:07 ` Sasha Levin
2014-03-14 0:50 ` Linus Torvalds
2014-03-13 23:12 ` Dave Jones
2014-03-14 18:31 ` Kees Cook
2014-03-14 18:33 ` Dave Jones
2014-03-14 19:08 ` Dave Jones [this message]
2014-03-14 19:31 ` Kees Cook
2014-03-14 19:32 ` Linus Torvalds
2014-03-14 19:41 ` Linus Torvalds
2014-03-14 20:15 ` Kees Cook
2014-03-14 20:08 ` Dave Jones
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=20140314190824.GA6426@redhat.com \
--to=davej@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sasha.levin@oracle.com \
--cc=torvalds@linux-foundation.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.