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  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 23:06:34 +0200
From:   Daniel Borkmann <>
To:     Toke Høiland-Jørgensen <>,
        David Ahern <>,
        David Ahern <>,
        David Ahern <>
Subject: Re: [PATCH v5 bpf-next 00/11] net: Add support for XDP in egress path

On 5/18/20 8:00 PM, Toke Høiland-Jørgensen wrote:
> David Ahern <> writes:
>> On 5/18/20 3:08 AM, Toke Høiland-Jørgensen wrote:
>> 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.
> I meant 'less powerful' in the obvious sense: it only sees a subset of
> the packets going out of the interface. And so I worry that it will (a)
> make an already hard to use set of APIs even more confusing, and (b)
> turn out to not be enough so we'll end up needing a "real" egress hook.
> As I said in my previous email, a post-REDIRECT hook may or may not be
> useful in its own right. I'm kinda on the fence about that, but am
> actually leaning towards it being useful; however, I am concerned that
> it'll end up being redundant if we do get a full egress hook.

I tend to agree with this. From a user point of view, say, one that has used
the ingress XDP path before, the expectation would very likely be that an XDP
"egress hook" would see all the traffic similarly as on the ingress side, but
since the skb path has been dropped in this revision - I agree with you, David,
that it makes sense to do so - calling it XDP "egress" then feels a bit misleading
wrt expectations. I'd assume we'd see a lot of confused users on this very list
asking why their BPF program doesn't trigger.

So given we neither call this hook on the skb path, nor XDP_TX nor AF_XDP's TX
path, I was wondering also wrt the discussion with John if it makes sense to
make this hook a property of the devmap _itself_, for example, to have a default
BPF prog upon devmap creation or a dev-specific override that is passed on map
update along with the dev. At least this would make it very clear where this is
logically tied to and triggered from, and if needed (?) would provide potentially
more flexibility on specifiying BPF progs to be called while also solving your


Powered by blists - more mailing lists