netdev - Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64_

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:   Thu, 11 May 2017 22:07:04 -0700
From:   Alexei Starovoitov <ast@...com>
To:     David Miller <davem@...emloft.net>
CC:     <daniel@...earbox.net>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__

On 5/11/17 6:29 PM, David Miller wrote:
> This whole thing go me thinking however.  What do you expect to happen
> on 32-bit architectures implementing an eBPF JIT?

I doubt any 32-bit cpu architectures will do JIT in the near future.
Doing 64-bit operations everywhere is too painful in assembler.
HW offloading is a different story. Like nfp has 32-bit registers
and everything 64-bit in bpf is not the ideal for them.
For such cases the idea is to teach verifier to recognize that
registers don't use upper 32-bits and mark them, so JITs can be
more efficient.

> That's going to
> create some serious conflicts and consternation wrt.  tracing which is
> going to want to use headers which are for sizeof(void *)==4 whereas
> for eBPF natively it's 8.

that is indeed a problem. The bpf tracing approach that includes
kernel headers mostly doesn't work on 32-bit archs, though
few iovisor/bcc scripts should be functional. Those that don't
walk pointers and relying on tracepoints instead.