linux-kernel - Re: [PATCH] arm:traps: Don't print stack or raw PC/LR values in backtraces

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] [day] [month] [year] [list]

Date:   Mon, 12 Oct 2020 12:06:44 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Xiaoming Ni <nixiaoming@...wei.com>, dima@...sta.com,
        will@...nel.org, jpoimboe@...hat.com, akpm@...ux-foundation.org,
        christian.brauner@...ntu.com, viro@...iv.linux.org.uk,
        ldufour@...ux.ibm.com, amanieu@...il.com, walken@...gle.com,
        ben.dooks@...ethink.co.uk, tglx@...utronix.de, mingo@...nel.org,
        vincent.whitchurch@...s.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, wangle6@...wei.com,
        luohaizheng@...wei.com
Subject: Re: [PATCH] arm:traps: Don't print stack or raw PC/LR values in
 backtraces

On Mon, Oct 12, 2020 at 12:03:18PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-10-11 22:32:38 [+0100], Russell King - ARM Linux admin wrote:
> > I don't have a problem getting rid of the hex numbers in [< >]
> > although then I will need to convert the symbol back to an address
> > using the vmlinux to then calculate its address to then find the
> > appropriate place in the objdump output - because objdump does
> > _not_ use the symbol+offset annotation.  Yes, I really do look up
> > the numeric addresses in the objdump output to then read the
> > disassembly.
> > 
> > $ objdump -d vmlinux | less
> > 
> > and then search for the address is the fastest and most convenient
> > way for me rather than having to deal with some random script.
> > 
> > Maybe I'm just antequated about how I do my debugging, but this
> > seems to me to be the most efficient and fastest way.
> 
> besides what Josh mentioned, there is also 
>          scripts/decode_stacktrace.sh path-vmlinux
>  
> where you can copy/paste your complete stack trace / dmesg and it will
> decode it line by line. So if you invoke
>         scripts/decode_stacktrace.sh vmlinux.o
> 
> and paste this:
> 
> |[    7.568155] 001: PC is at do_work_pending+0x190/0x5c4
> |[    7.568641] 001: LR is at slow_work_pending+0xc/0x20
> |[    7.569232] 001: Backtrace:
> |[    7.569367] 001: [<c020c2d0>] (do_work_pending) from [<c02000cc>] (slow_work_pending+0xc/0x20)
> 
> you get this in return:
> |[    7.568155] 001: PC is at do_work_pending (arch/arm/kernel/signal.c:616 arch/arm/kernel/signal.c:670)
> |[    7.568641] 001: LR is at slow_work_pending (arch/arm/kernel/entry-common.S:112)
> |[    7.569232] 001: Backtrace:
> |[    7.569367] 001: (do_work_pending) from slow_work_pending (arch/arm/kernel/entry-common.S:112)

That's assuming:

1) you have built the kernel with debug information enabled
   (I never do, it uses way too much disk space)
2) you want to look at the C code rather than the assembly.

I think you've assumed that I debug oopses by looking primerily at C
code. I don't. I understand the assembly and then look at the C code.

I've stated in the past in detail how I debug the kernel when someone
has posted a hard-to-debug oops, going through the validation of the
dumped state, sometimes to find the bug in a function several parents
up from the one where the oops actually occurred.

However, as I've said, I have little problem removing the hex values
inside [< >] as I can work around that. Removing the other information
is what I'm objecting to.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!