Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters

[Daniel Borkmann <dborkman@redhat.com>]

On 02/14/2014 05:47 AM, Alexei Starovoitov wrote:
...
>> Do you see a possibility to integrate your work step by step? That is,
>
> Sure. let's see how we can do it.
>
>> to first integrate the interpreter part only; meaning, to detect "old"
>> BPF programs e.g. coming from SO_ATTACH_FILTER et al and run them in
>> compatibility mode while extended BPF is fully integrated and replaces
>> the old engine in net/core/filter.c. Maybe, "old" programs can be
>
> do you mean drop bfp64_jit, checker and just have bpf32->bpf64 converter
> and bpf64 interpreter as phase 1 ?
> Checking is done by old bpf32,
> all existing bpf32 jits, if available, can convert bpf32 to native,
> but interpreter will be running on bpf64 ?
> phase 2 to introduce bpf64_x86 jit and so on?
> Sounds fine.

If that's possible, so first step would be to migrate bpf_run() from patch1
into sk_run_filter() form net/core/filter.c, and also bring in related
include file into include/linux/filter.h resp. include/uapi/linux/filter.h.
Plus code that is needed to verify the image in new (and old) format e.g.
bpf_load_image() et al, and to either convert old programs into the new
format, for example; generally, to find a way to still handle them (bpf/seccomp)
while having the new code included and leaving new JITs aside. That I think
could be phase 1. Phase 2 would be to successively replace current JITs, etc.

> Today I didn't try to optimize bpf64 interpreter, since insn set is designed
> for eventual JITing and interpreter is there to support archs that don't
> have jit yet.
> I guess I have to tweak it to perform at bpf32 interpreter speeds.
>
>> transformed transparently to the new representation and then would be
>> good to execute in eBPF. If possible, in such a way that in the first
>> step JIT compilers won't need any upgrades. Once that is resolved,
>> JIT compilers could successively migrate, arch by arch, to compile the
>> new code? And last but not least the existing tools as well for handling
>> eBPF. I think, if possible, that would be great. Also, I unfortunately
>> haven't looked into your code too deeply yet due to time constraints,
>> but I'm wondering e.g. for accessing some skb fields we currently use
>> the "hack" to "overload" load instructions with negative arguments. Do
>> we have a sort of "meta" instruction that is extendible in eBPF to avoid
>> such things in future?
>
> Exactly.
> This 'negative offset' hack of bpf32 isn't very clean, since jits for all archs
> need to change when new offsets added.
> For bpf64 I'm proposing a customizable 'bpf_context' and variable set
> of bpf-callable functions, so JITs don't need to change and verifier
> stays the same.
> That's the idea behind 'bpf_callbacks' in include/linux/bpf_jit.h
>
> Some meta data makes sense to pass as input into bpf program.
> Like for seccomp 'bpf_context' can be 'struct seccomp_data'
>
> For networking, bpf_context can be 'skb',
> then bpf_s_anc_protocol becomes a normal 2-byte bpf64 load
> from skb->protocol field. Allowing access to other fields of skb
> is just a matter of defining permissions of 'struct bpf_context' in
> bpf_callback->get_context_access()
>
> Some other meta data and extensions are cleaner when defined
> as function calls from bpf, since calls are free.
> I think bpf_table_lookup() is a fundamental one that allows to define
> arbitrary tables within bpf and access them from the program.
> (here I need feedback the most whether to access tables
> via netlink from userspace or via debugfs...)
>
> It probably will be easier to read the code of bpf32-bpf64 converter
> to understand the differences between the two.
> I guess I have to start working on the converter sooner than I thought...
>
> Thanks
> Alexei
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>