netdev - Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP

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: <811f498d-8503-78b2-1ddb-ddafdec5a385@redhat.com>
Date:   Fri, 10 Feb 2017 13:42:36 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Tom Herbert <tom@...bertland.com>,
        David Miller <davem@...emloft.net>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH RFC v2 1/8] xdp: Infrastructure to generalize XDP



On 2017年02月10日 10:30, Tom Herbert wrote:
> On Thu, Feb 9, 2017 at 5:48 PM, David Miller <davem@...emloft.net> wrote:
>> From: Tom Herbert <tom@...bertland.com>
>> Date: Thu, 9 Feb 2017 15:08:22 -0800
>>
>>> Okay, how about this... I'll add a configuration option like
>>> XDP_ALLOW_OTHER_HOOKS. The default will be to disallow setting any
>>> hook other than a BPF. If it is set, then we'll accept other hooks
>>> to be run. This way mostly restrict the interface by default, but
>>> still allow experimentation with other hook types like I need with
>>> TXDP or maybe the netfilter guys might want to fastpath netfilter
>>> etc. When we we bring a working robust implementation to netdev that
>>> show clear benefits then we can add those to BPF as the "allowed"
>>> hooks at that time. So this strictly controls the interfaces, but
>>> still also allows room for innovation.
>> Anyone is allowed to "innovate" in their own private kernel tree.
>>
>> But I'm not unleashing that upstream.
>>
>> The only reason I accepted XDP is entirely because it is limited
>> in scope to eBPF.  All eBPF programs execute in finite time,
>> cannot loop, cannot deadlock, cannot access arbitrary pieces
>> of kernel memory and datastructures.
>>
>> It is a well defined, constrained, and incredibly tightly controlled
>> execution environment for implementing policy, monitoring and control.
> And it's also incredibly invasive in the core data path of drivers.
> TBH it is not clear to me that the narrow use cases for XDP justifies
> adding this complexity being added to every driver.

XDP is valuable for fast userspace forwarding (e.g macvtap passthrough 
mode). I hope we can leave a window for this. Or we may need introduce 
other similar hooks.

Thanks

>
> In any case, I withdraw the patch set.
>
> Tom