netdev - Re: llvm-objdump...

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: <20170428.121710.1780087759147659481.davem@davemloft.net>
Date:   Fri, 28 Apr 2017 12:17:10 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     ast@...com
Cc:     daniel@...earbox.net, netdev@...r.kernel.org
Subject: Re: llvm-objdump...

From: Alexei Starovoitov <ast@...com>
Date: Tue, 25 Apr 2017 20:48:52 -0700

> On 4/25/17 10:13 AM, David Miller wrote:
>>
>> I think there are some endianness issues ;-)
>>
>> davem@...ience:~/src/GIT/net-next/tools/testing/selftests/bpf$
>> llvm-objdump -S x.o
> 
> nice host name ;)
> 
>> x.o:    file format ELF64-BPF
>>
>> Disassembly of section test1:
>> process:
>>        0:       b7 00 00 00 00 00 00 02         r0 = 33554432
>>        1:       61 21 00 50 00 00 00 00         r1 = *(u32 *)(r2 + 20480)
>>
>> That first instruction should be "r0 = 2"
> 
> hmm. I haven't tested it on big endian.
> When last time s390 folks tested samples/bpf with llvm we didn't even
> have automatic -march=bpf in llvm, so they used -march=bpfeb.
> There was no llvm-objdump support either.
> 
> llvm side does this:
> tatic Triple::ArchType parseBPFArch(StringRef ArchName) {
>   if (ArchName.equals("bpf")) {
>     if (sys::IsLittleEndianHost)
>       return Triple::bpfel;
>     else
>       return Triple::bpfeb;
>   } else if (ArchName.equals("bpf_be") || ArchName.equals("bpfeb")) {
>     return Triple::bpfeb;
>   } else if (ArchName.equals("bpf_le") || ArchName.equals("bpfel")) {
>     return Triple::bpfel;
> 
> It works for clang and for llvm.
> I thought llvm-objdump should infer triple from elf file
> and do the 'right thing'... hmm
> 
> could you please test it with -g and see whether dwarf is still
> correct in .o ?
> llvm-objdump -S should print original C code next to asm.
> Hope bpf dwarf is not broken on big-endian...

Even if I give it -triple=bpfeb it emits immediates incorrectly.

The bug is certainly in the insn field fetcher of the disassembler.