netdev - Re: eBPF - little-endian load instructions?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170414184228.GA41922@ast-mbp.thefacebook.com>
Date:   Fri, 14 Apr 2017 11:42:30 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>
Subject: Re: eBPF - little-endian load instructions?

On Thu, Apr 13, 2017 at 07:58:45AM +0200, Johannes Berg wrote:
> On Wed, 2017-04-12 at 20:08 -0700, Alexei Starovoitov wrote:
> 
> > it's really llvm bug that i need fix. It's plain broken
> > to generate what effectively is nop insn for march=bpfeb
> > My only excuse that when that code was written llvm had only
> > march=bpfel.
> > bpfeb was added much later.
> 
> So I'm confused now. Is bpf intended to be endian-independent or not?
> It sounded at first like it was, even if I have a hard time imagining
> how that would even work.

bpf takes endianness of the cpu it runs on.
if we said that bpf 32-bit load insn is little endian, it would have screwed up
all big-endian archs and the other way around.
For both classic and extended the corresponding struct sock_filter and bpf_insn
are encoded in target cpu endianness.
The front-end (clang) needs to run in target endianness as well otherwise
the bcc tracing scripts will be accessing garbage.
In other words you cannot take either classic or extended bpf program
generated for x86 and run it on big-endian. Though you can compile on x86
and run on Arm. Hence two targets for llvm -march=bpfeb and -march=bpfel
If you compile for -march=bpfeb and try to load on x86, the instruction stream
will be rejected by the verifier in early stages, since branch insns and
all immediate values will be wrong.