netdev - Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path

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:   Sun, 2 Feb 2020 10:43:58 -0700
From:   David Ahern <dsahern@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        David Ahern <dsahern@...il.com>, netdev@...r.kernel.org,
        prashantbhole.linux@...il.com, jasowang@...hat.com,
        davem@...emloft.net, jbrouer@...hat.com, mst@...hat.com,
        toshiaki.makita1@...il.com, daniel@...earbox.net,
        john.fastabend@...il.com, ast@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, andriin@...com
Subject: Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP programs
 in the egress path

On 1/28/20 6:57 AM, Jakub Kicinski wrote:
> On Mon, 27 Jan 2020 20:43:09 -0700, David Ahern wrote:
>>> end of whatever is doing the redirect (especially with Alexei's work   
>>
>> There are use cases where they may make sense, but this is not one.
>>
>>> on linking) and from cls_bpf 🤷‍♂️
>>
>> cls_bpf is tc based == skb, no? I want to handle any packet, regardless
>> of how it arrived at the device's xmit function.
> 
> Yes, that's why I said you need the same rules in XDP before REDIRECT
> and cls_bpf. Sure it's more complex, but (1) it's faster to drop in
> the ingress prog before going though the entire redirect code and
> without parsing the packet twice and (2) no extra kernel code necessary.

you are making a lot of assumptions and frankly it's the 'c' word
(complex) that I want to avoid. I do not believe in the OVS style of
packet processing - one gigantic program with a bunch of logic and data
driven flow lookups that affect every packet. I prefer simple, singly
focused programs logically concatenated to make decisions. Simpler
management, simpler lifecycle. The scope, scale and lifecycle management
of VMs/containers is just as important as minimizing the cycles spent
per packet. XDP in the Tx path is a missing primitive to make life simple.

As an example, the program on the ingress NICs to the host can be
nothing more than a demux'er - use the ethernet header and vlan
(preferably with vlan offload enabled) to do a <vlan,mac> lookup. No
packet parsing at all at this level. The lookup returns an index of
where to redirect the packet (e.g., the tap device of a VM). At the same
time, packets can hit the "slow path" - processing support from the full
stack when it is needed and still packets end up at the tap device. *IF*
there is an ingress ACL for that tap device managed by the host, it can
exist in 1 place - a program and map attached to the tap device limited
to that tap device's networking function (VMs can have multiple
connections to different networks with different needs at this point),
and the program gets run for both XDP fast path and skb slow path.