From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753382AbdK1Ror (ORCPT <rfc822;w@1wt.eu>);
        Tue, 28 Nov 2017 12:44:47 -0500
Received: from smtp-out6.electric.net ([192.162.217.192]:55477 "EHLO
        smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752361AbdK1Rop (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 28 Nov 2017 12:44:45 -0500
From: David Laight <David.Laight@ACULAB.COM>
To: "'Linus Torvalds'" <torvalds@linux-foundation.org>,
        "Eric W. Biederman" <ebiederm@xmission.com>
CC: "Tobin C. Harding" <me@tobin.cc>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        "Theodore Ts'o" <tytso@mit.edu>, Kees Cook <keescook@chromium.org>,
        "Paolo Bonzini" <pbonzini@redhat.com>, Tycho Andersen <tycho@tycho.ws>,
        "Roberts, William C" <william.c.roberts@intel.com>,
        Tejun Heo <tj@kernel.org>,
        "Jordan Glover" <Golden_Miller83@protonmail.ch>,
        Greg KH <gregkh@linuxfoundation.org>, Petr Mladek <pmladek@suse.com>,
        Joe Perches <joe@perches.com>, Ian Campbell <ijc@hellion.org.uk>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <wilal.deacon@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>, Chris Fries <cfries@google.com>,
        Dave Weinstein <olorin@google.com>,
        Daniel Micay <danielmicay@gmail.com>,
        Djalal Harouni <tixxdz@gmail.com>,
        =?utf-8?B?UmFkaW0gS3JjbcOhcg==?= <rkrcmar@redhat.com>,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        KVM list <kvm@vger.kernel.org>,
        "kernel-hardening@lists.openwall.com" 
        <kernel-hardening@lists.openwall.com>
Subject: RE: [PATCH 0/5] add printk specifier %px, unique identifier
Thread-Topic: [PATCH 0/5] add printk specifier %px, unique identifier
Thread-Index: AQHTaG76s5gJiP9r+U2yQsu84EU3hqMqDpNQ
Date: Tue, 28 Nov 2017 17:44:54 +0000
Message-ID: <e08761e892c94bedb9778fd760958e07@AcuMS.aculab.com>
References: <1511826058-2563-1-git-send-email-me@tobin.cc>
 <CA+55aFyO6sKuE16z6hgocRA8Azd6E7sO4CO=AogxF1m6vaTh4A@mail.gmail.com>
 <CA+55aFzDh7GpkKniTgQp29-6TObR8NpOKczbAW-85qux=ek0Tw@mail.gmail.com>
 <874lpelxzh.fsf@xmission.com>
 <CA+55aFx+bMOT-DDp3EYuio0aJDGzWa3PzQxVbM3Rz+GdZKaaFQ@mail.gmail.com>
In-Reply-To: <CA+55aFx+bMOT-DDp3EYuio0aJDGzWa3PzQxVbM3Rz+GdZKaaFQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.202.99.200]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-Outbound-IP: 156.67.243.126
X-Env-From: David.Laight@ACULAB.COM
X-Proto: esmtps
X-Revdns: 
X-HELO: AcuMS.aculab.com
X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256
X-Authenticated_ID: 
X-PolicySMART: 3396946, 3397078
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id vASHipq1025859

From: Linus Torvalds
> Sent: 28 November 2017 17:33
> 
> On Mon, Nov 27, 2017 at 10:26 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> >>
> >> Oh well, I just did /proc/<pid>/stack by making it just print 0
> >> unconditionally rather than the hex number.
> >
> > Patch?
> 
> Oh, apparently I never pushed out yesterday.
> 
> The patch literally just affects the (useless) hex number. So:
> 
>     cat /proc/self/stack
> 
> now prints out
> 
>     [<0>] proc_pid_stack+0xaa/0x100
>     [<0>] proc_single_show+0x48/0x80
>     [<0>] seq_read+0xd2/0x410
>     ...
> 
> instead of putting some randomized kernel address there.

Not sure I've done it on Linux - getting a hexdump of the stack is hard.
But I know I've used the absolute return addresses to help hand-decode
the stack.
Usually needed to work out which stack frame is which - especially when the
stack decode doesn't actually (obviously) contain the addresses of each frame.

I don't know how these new stack traceback methods work, but the best one
I've seen in the past disassembled forwards remembering the stack offset
and unprocessed branch targets until it found a return address.
It only had to track %sp and %bp.

	David