netdev - Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through chain calls

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] [day] [month] [year] [list]

Message-ID: <20191007210117.6b2mvhkcysmsgfnv@ast-mbp.dhcp.thefacebook.com>
Date:   Mon, 7 Oct 2019 14:01:19 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Lorenz Bauer <lmb@...udflare.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Song Liu <songliubraving@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>, Martin Lau <kafai@...com>,
        Yonghong Song <yhs@...com>,
        Marek Majkowski <marek@...udflare.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        kernel-team <kernel-team@...udflare.com>
Subject: Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single
 interface through chain calls

On Mon, Oct 07, 2019 at 05:43:44PM +0100, Edward Cree wrote:
> 
> (Although I also think full-blown dynamically-linked calls ought not to be
>  impossible, *if* we restrict them to taking a ctx and returning a u64, in
>  which case the callee can be verified as though it were a normal program,
>  and the caller's verifier just treats the program as returning an unknown
>  scalar.  The devil is in the details, though, and it seems no-one's quite
>  wanted it enough to do the work required to make it happen.)

Absolutely.
Full dynamic linking and libraries is on todo list.
It's taking long time, since it needs to be powerful and generic from the day one.
If we do 'pass ctx only and return u64' as a stop gap, it will be just as limited
as existing bpf_tail_calls.
bpf_tail_call api was badly designed.
I couldn't figure out how to make tail calls safe and generic, so I came up
with this bpf_tail_call hack. bpf usability suffers.
The verifier is different now. It's powerful enough to do true calls and jumps.
Especially with BTF it can see and track all types.
True tail calls will be seen as indirect jump assembler insn.
True indirect calls will be seen as indirect call assembler insn.
The choice of opcode encoding is clear.
The verifier, interpreter, and JIT work left.
It won't take long.