netdev - Re: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other

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: <e968af34-b538-d1d3-1cf1-5b4e22294a78@solarflare.com>
Date:   Tue, 22 Oct 2019 00:51:11 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        "John Fastabend" <john.fastabend@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Marek Majkowski <marek@...udflare.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Alan Maguire <alan.maguire@...cle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        "David Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF
 programs after each other

On 15/10/2019 19:33, Edward Cree wrote:
> But I think we'll
>  need to prototype things with static linking first so that we can be
>  sure of the linker semantics we want, before we try to put a new dynamic
>  linker in the kernel.
For anyone wanting to follow my progress on this, the first-draft eBPF
 linker 'ebld.py' can now be found at
 https://github.com/solarflarecom/ebpf_asm/tree/linker

It's able to resolve inter-object calls (at least in a _really simple_ test
 I did, where prog A was "call pass_fn; exit" and prog B was "pass_fn:
 ld r0, XDP_PASS; exit"), but I haven't got as far as feeding the resulting
 object file to the kernel (no obvious reason that shouldn't work, I just
 haven't tried it yet).
What it _doesn't_ do yet is deal with BTF — it just silently discards any
 BTF or BTF.ext sections in the input object files.  I'll need to re-read
 the BTF spec to see what's changed there since last I was involved (I hope
 the spec has been kept up to date as BTF has evolved...!)

But with the basic linker there, I think a prototype daemon is probably a
 higher priority than getting fully-featured with BTF, so that's what I
 plan to do next.

-Ed

PS: Yes, it's in Python.  I started out in C, and quickly backed myself
 into a corner trying to keep the data structures simple.  Having first-
 class dictionaries Really Helps.