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

Date:   Wed, 2 Oct 2019 17:35:26 +0100
From:   Lorenz Bauer <lmb@...udflare.com>
To:     Toke Høiland-Jørgensen <toke@...hat.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>,
        David Miller <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Networking <netdev@...r.kernel.org>, bpf <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 Wed, 2 Oct 2019 at 14:30, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> This series adds support for executing multiple XDP programs on a single
> interface in sequence, through the use of chain calls, as discussed at the Linux
> Plumbers Conference last month:

Hi Toke,

Thanks for posting the patch set! As I mentioned, this is a big pain
point for us as
well. Right now, all of our different XDP components are managed by a single
daemon called (drumroll) xdpd. We'd like  to separate this out into
individual bits and pieces that operate separately from each other.

I've looked at the kernel side of your patch set, here are my thoughts:

> # HIGH-LEVEL IDEA
>
> The basic idea is to express the chain call sequence through a special map type,
> which contains a mapping from a (program, return code) tuple to another program
> to run in next in the sequence. Userspace can populate this map to express
> arbitrary call sequences, and update the sequence by updating or replacing the
> map.

How do you imagine this would work in practice? From what I can tell, the map
is keyed by program id, which makes it difficult to reliably construct
the control
flow that I want.

As an example, I'd like to split the daemon into two parts, A and B,
which I want
to be completely independent. So:

- A runs before B, if both are active
- If A is not active, B is called first
- If B is not active, only A is called

Both A and B may at any point in time replace their current XDP program with a
new one. This means that there is no stable program ID I can use.

Another problem are deletions: if I delete A (because that component
is shut down)
B will never be called, since the program ID that linked B into the
control flow is gone.
This means that B needs to know about A and vice versa.

> The actual execution of the program sequence is done in bpf_prog_run_xdp(),
> which will lookup the chain sequence map, and if found, will loop through calls
> to BPF_PROG_RUN, looking up the next XDP program in the sequence based on the
> previous program ID and return code.

I think that the tail call chain is useful for other eBPF programs as well.
How hard is it to turn the logic in bpf_prog_run_xdp into a helper
instead?

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com