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 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?

Powered by blists - more mailing lists