linux-kernel - Re: [RFC] Add RIP to scripts/decodecode

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]

Date:   Tue, 29 Sep 2020 15:22:55 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Marc Zyngier <maz@...terjones.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Will Deacon <will@...nel.org>, Rabin Vincent <rabin@....in>,
        x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Add RIP to scripts/decodecode

On Tue, Sep 29, 2020 at 01:40:03PM +0100, Marc Zyngier wrote:
> Hi,
> 
> [dropping these ARM people I never heard of...]

Yeah, I completely forgot that those ARM folks are not there anymore,
thx! :-)

> Looks neat. Only objection is that RIP is pretty tainted from an
> architecture perspective. How about PC instead, which most people
> understand immediately?

Sure.

> Bonus points if you can convince decodecode to grok something such
> as "do_undefinstr+0x2e0/0x2f0" as the PC! ;-)

Well, I thought about it. And I don't know how the splats look on ARM
but on x86 we're not dumping the actual PC contents anymore:

[  477.366747][T23917] KASAN: null-ptr-deref in range [0x0000000000000100-0x0000000000000107]
[  477.374897][T23917] CPU: 1 PID: 23917 Comm: syz-executor.0 Not tainted 5.9.0-rc7+ #1
[  477.376375][T23917] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
[  477.378098][T23917] RIP: 0010:gfs2_rgrp_dump+0x37/0x660
			^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

so I could make the splat code dump PC again, but in brackets:

[  477.378098][T23917] RIP: 0010:gfs2_rgrp_dump+0x37/0x660 (0xffffffff8329a927)

or I would have to somehow have access to vmlinux or symbols which would
give me the function address. But that is not always the case - most of
the time you see a splat somewhere and that's all.

Unless you have a better idea...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette