netdev - Re: [PATCH v5 bpf-next 00/11] net: Add support for XDP in 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:   Mon, 18 May 2020 08:44:44 -0600
From:   David Ahern <dsahern@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org,
        prashantbhole.linux@...il.com, brouer@...hat.com,
        daniel@...earbox.net, john.fastabend@...il.com, ast@...nel.org,
        kafai@...com, songliubraving@...com, yhs@...com, andriin@...com,
        David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH v5 bpf-next 00/11] net: Add support for XDP in egress path

On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
> I can see your point that fixing up the whole skb after the program has
> run is not a good idea. But to me that just indicates that the hook is
> in the wrong place: that it really should be in the driver, executed at
> a point where the skb data structure is no longer necessary (similar to
> how the ingress hook is before the skb is generated).

Have you created a cls_bpf program to modify skbs? Have you looked at
the helpers, the restrictions and the tight management of skb changes?
Have you followed the skb from create to device handoff through the
drivers? Have you looked at the history of encapsulations, gso handling,
offloads, ...? I have and it drove home that the skb path and xdp paths
are radically different. XDP is meant to be light and fast, and trying
to cram an skb down the xdp path is a dead end.

> 
> Otherwise, what you're proposing is not an egress hook, but rather a
> 'post-REDIRECT hook', which is strictly less powerful. This may or may
> not be useful in its own right, but let's not pretend it's a full egress
> hook. Personally I feel that the egress hook is what we should be going
> for, not this partial thing.

You are hand waving. Be specific, with details.

Less powerful how? There are only so many operations you can do to a
packet. What do you want to do and what can't be done with this proposed
change? Why must it be done as XDP vs proper synergy between the 2 paths.