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]

Message-ID: <b18c145f7b96cace7cd503de33c08311@misterjones.org>
Date:   Tue, 29 Sep 2020 13:40:03 +0100
From:   Marc Zyngier <maz@...terjones.org>
To:     Borislav Petkov <bp@...en8.de>
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

Hi,

[dropping these ARM people I never heard of...]

On 2020-09-29 12:32, Borislav Petkov wrote:
> Hi,
> 
> how about we add RIP to decodecode output? See below.
> 
> I've added the couple of people to Cc who seem to use this thing. The
> patch is dirty and needs cleaning still but I think it would be cool to
> have the actual addresses in that output so that when you compare with
> objdump output in another window, you can find the code very quickly.
> 
> You'd need to supply the rIP from the splat, though, as an env var:
> 
> $ RIP=0xffffffff8329a927 ./scripts/decodecode < ~/tmp/syz/gfs2.splat
> [ 477.379104][T23917] Code: 48 83 ec 28 48 89 3c 24 48 89 54 24 08 e8
> c1 b4 4a fe 48 8d bb 00 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89
> fa 48 c1 ea 03 <80> 3c 02 00 0f 85 97 05 00 00 48 8b 9b 00 01 00 00 48
> 85 db 0f 84
> Cleaned: [48 83 ec 28 48 89 3c 24 48 89 54 24 08 e8 c1 b4 4a fe 48 8d
> bb 00 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
> 3c 02 00 0f 85 97 05 00 00 48 8b 9b 00 01 00 00 48 85 db 0f 84]
> Marker: 127
> rIP_sub: 42
> adj_vma: 0xffffffff8329a8fd
> All code
> ========
> ffffffff8329a8fd:       48 83 ec 28             sub    $0x28,%rsp
> ffffffff8329a901:       48 89 3c 24             mov    %rdi,(%rsp)
> ffffffff8329a905:       48 89 54 24 08          mov    %rdx,0x8(%rsp)
> ffffffff8329a90a:       e8 c1 b4 4a fe          callq  
> 0xffffffff81745dd0
> ffffffff8329a90f:       48 8d bb 00 01 00 00    lea    0x100(%rbx),%rdi
> ffffffff8329a916:       48 b8 00 00 00 00 00    movabs 
> $0xdffffc0000000000,%rax
> ffffffff8329a91d:       fc ff df
> ffffffff8329a920:       48 89 fa                mov    %rdi,%rdx
> ffffffff8329a923:       48 c1 ea 03             shr    $0x3,%rdx
> ffffffff8329a927:*      80 3c 02 00             cmpb
> $0x0,(%rdx,%rax,1)               <-- trapping instruction
> ffffffff8329a92b:       0f 85 97 05 00 00       jne    
> 0xffffffff8329aec8
> ffffffff8329a931:       48 8b 9b 00 01 00 00    mov    0x100(%rbx),%rbx
> ffffffff8329a938:       48 85 db                test   %rbx,%rbx
> ffffffff8329a93b:       0f                      .byte 0xf
> ffffffff8329a93c:       84                      .byte 0x84
> 
> Code starting with the faulting instruction
> ===========================================
> ffffffff8329a8fd:       80 3c 02 00             cmpb   
> $0x0,(%rdx,%rax,1)
> ffffffff8329a901:       0f 85 97 05 00 00       jne    
> 0xffffffff8329ae9e
> ffffffff8329a907:       48 8b 9b 00 01 00 00    mov    0x100(%rbx),%rbx
> ffffffff8329a90e:       48 85 db                test   %rbx,%rbx
> ffffffff8329a911:       0f                      .byte 0xf
> ffffffff8329a912:       84                      .byte 0x84
> 

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

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

Thanks,

         M.
-- 
Who you jivin' with that Cosmik Debris?