netdev - Re: [PATCH bpf-next 0/3] Introduce pinnable bpf

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]

Message-ID: <38347de1-2564-0184-e126-218a5f2a4b95@gmail.com>
Date:   Fri, 6 Mar 2020 11:09:26 -0700
From:   David Ahern <dsahern@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Alexei Starovoitov <ast@...com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel
 abstraction

On 3/6/20 3:25 AM, Daniel Borkmann wrote:
>>
>> Presumably the XDP EGRESS hook that David Ahern is working on will make
>> this doable for XDP on veth as well?
> 
> I'm not sure I see a use-case for XDP egress for Cilium yet, but maybe
> I'm still
> lacking a clear picture on why one should use it. We currently use various
> layers where we orchestrate our BPF programs from the agent. XDP/rx on
> the phys
> nic on the one end, BPF sock progs attached to cgroups on the other end
> of the
> spectrum. The processing in between on virtual devices is mainly
> tc/BPF-based
> since everything is skb based anyway and more flexible also with
> interaction
> with the rest of the stack. There is also not this pain of having to
> linearize
> all the skbs, but at least there's a path to tackle that.
> 


{ veth-host } <----> { veth-container }

If you are currently putting an XDP program on veth-container, it is run
on the "Rx" of the packet from the host. That program is visible to the
container, but is managed by the host.

With XDP Tx you can put the same program on veth-host.

For containers, sure, maybe you don't care since you control all aspects
of the networking devices. For VMs, the host does not have access to or
control of the "other end" in the guest. Putting a program on the tap's
"Tx" side allows host managed, per-VM programs.