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]

Message-ID: <d705cf50-b5b3-8778-16fe-3a29b9eb1e85@iogearbox.net>
Date:   Tue, 19 May 2020 15:31:20 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     David Ahern <dsahern@...il.com>,
        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,
        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/19/20 2:02 AM, David Ahern wrote:
> On 5/18/20 3:06 PM, Daniel Borkmann wrote:
>> 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
>> use-case.
> 
> You lost me on the 'property of the devmap.' The programs need to be per
> netdevice, and devmap is an array of devices. Can you elaborate?

I meant that the dev{map,hash} would get extended in a way where the
__dev_map_update_elem() receives an (ifindex, BPF prog fd) tuple from
user space and holds the program's ref as long as it is in the map slot.
Then, upon redirect to the given device in the devmap, we'd execute the
prog as well in order to also allow for XDP_DROP policy in there. Upon
map update when we drop the dev from the map slot, we also release the
reference to the associated BPF prog. What I mean to say wrt 'property
of the devmap' is that this program is _only_ used in combination with
redirection to devmap, so given we are not solving all the other egress
cases for reasons mentioned, it would make sense to tie it logically to
the devmap which would also make it clear from a user perspective _when_
the prog is expected to run.

Thanks,
Daniel