linux-kernel - Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick

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: <CALx6S374fUxDd1_=db8hg4YsMoMZ_UwM3_uNW4JsXbVkHUEmHQ@mail.gmail.com>
Date:	Fri, 5 Aug 2016 07:41:40 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Daniel Borkmann <daniel@...earbox.net>
Cc:	Andi Kleen <andi@...stfloor.org>,
	John Fastabend <john.fastabend@...il.com>,
	"Liang, Kan" <kan.liang@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>, peterz@...radead.org,
	Alexey Kuznetsov <kuznet@....inr.ac.ru>,
	James Morris <jmorris@...ei.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
	Patrick McHardy <kaber@...sh.net>, akpm@...ux-foundation.org,
	Kees Cook <keescook@...omium.org>, viro@...iv.linux.org.uk,
	gorcunov@...nvz.org, John Stultz <john.stultz@...aro.org>,
	Alex Duyck <aduyck@...antis.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	David Decotigny <decot@...glers.com>,
	Florian Westphal <fw@...len.de>,
	Alexander Duyck <alexander.duyck@...il.com>,
	rdunlap@...radead.org, Cong Wang <xiyou.wangcong@...il.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>
Subject: Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue

On Thu, Aug 4, 2016 at 5:17 PM, Daniel Borkmann <daniel@...earbox.net> wrote:
> On 08/05/2016 12:54 AM, Andi Kleen wrote:
>>>
>>> +1, I tried to bring this up here [1] in the last spin. I think only very
>>> few changes would be needed, f.e. on eBPF side to add a queue setting
>>> helper function which is probably straight forward ~10loc patch; and with
>>> regards to actually picking it up after clsact egress, we'd need to adapt
>>> __netdev_pick_tx() slightly when CONFIG_XPS so it doesn't override it.
>>
>>
>> You're proposing to rewrite the whole net policy manager as EBPF and run
>> it in a crappy JITer? Is that a serious proposal? It just sounds crazy
>> to me.
>>
>> Especially since we already have a perfectly good compiler and
>> programming language to write system code in.
>>
>> EBPF is ok for temporal instrumentation (if you somehow can accept
>> its security challenges), but using it to replace core
>> kernel functionality (which network policy IMHO is) with some bizarre
>> JITed setup and multiple languages doesn't really make any sense.
>>
>> Especially it doesn't make sense for anything with shared state,
>> which is the core part of network policy: it negotiates with multiple
>> users.
>>
>> After all we're writing Linux here and not some research toy.
>
>
> From what I read I guess you didn't really bother to look any deeper into
> this bizarre "research toy" to double check some of your claims. One of the
> things it's often deployed for by the way is defining policy. And the
> suggestion here was merely to explore existing infrastructure around things
> like tc and whether it already resolves at least a part of your net policy
> manager's requirements (like queue selection) or whether existing
> infrastructure
> can be extended with fewer complexity this way (as was mentioned with a new
> cls module as one option).

+1. The SO_REUSEPORT + BPF patches have already demonstrated the value
of making policy in the kernel programmable. There's no reason to
believe that model can't be extended to cover packet steering in the
data path for TX or RX as well as other cases.

Tom