linux-kernel - Re: [RFC] improve_stack: make stack dump output useful again

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwDKSKyxC4rTBiFMRVr6xYtL96ZYCQqNSVLJV0-=FLTUg@mail.gmail.com>
Date:	Thu, 13 Mar 2014 15:03:41 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] improve_stack: make stack dump output useful again

On Thu, Mar 13, 2014 at 8:16 AM, Sasha Levin <sasha.levin@...cle.com> wrote:
>
> I've looked into doing it in the kernel, but it seems that it would require
> a rather
> large code addition just to deal with getting pretty line numbers.

No no no. The *kernel* will never do line numbers, especially since
only people who don't care about build performance compile with debug
info, and even if you do do that, the kernel won't load it anyway.

You missed the point.

The kernel is going to *remove* all the hex numbers that your script
relies on, because those hex numbers are completely worthless. They
are worthless and annoying now, but they are *doubly* worthless if the
kernel is compiled with base address randomization, since nobody will
know what the hex numbers mean.

> Unless I'm missing something big, is it really worth it?

You're missing something big. The patch I sent earlier *is* going to
happen one of these days, possible for 3.15. So your script that looks
at hex numbers is broken.

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*.

          Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/