netdev - Re: [ovs-dev] [RFC: add openvswitch actions using BPF 2/2] openvswitch: implements the BPF

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:	Thu, 5 Feb 2015 11:34:50 -0800
From:	Andy Zhou <azhou@...ira.com>
To:	Thomas Graf <tgraf@...ronetworks.com>
Cc:	"dev@...nvswitch.com" <dev@...nvswitch.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [ovs-dev] [RFC: add openvswitch actions using BPF 2/2]
 openvswitch: implements the BPF_PROG action in datapath

On Thu, Feb 5, 2015 at 7:07 AM, Thomas Graf <tgraf@...ronetworks.com> wrote:
> On 02/04/15 at 02:48pm, Andy Zhou wrote:
>> BPF_PROG action allows an action to be implemented in eBPF language and
>> downloaded by the userspace at runtime.
>>
>> Signed-off-by: Andy Zhou <azhou@...ira.com>
>
> Thanks a lot for putting this together Andy and Joe and everybody else
> who was involved. This is much further than what I expected as a first
> step.
>
> One slight open from my side is the avoidance of versioning help of
> helpers. We want to avoid v2, v3, ... helpers if the need should arise
> to extend an existing helper.

I share the concern. Addressing this upfront is a good idea. On the other hand
I am not sure if this is completely avoidable at a reasonable cost.
>
> I think it should be doable with BPF to have the verifier accept if
> a helper is called with less args than expected, to initialize those
> to 0. This would allow for helpers to support additional arguments.
I am not sure it is fundamentally better than V2, v3...   On the other hand,
I agree this looks technically possible.
>
> I think this needs to be documented and expectations should be clear.
> Other than that I'm very very happy with where this is going.
Agreed,

> It seems very doable to also allow for a BPF prog to be registered
> upon flow table miss.
Yes, this is possible, but at the cost of flow set up rate. It may
still be practical
with some optimization, such as caching action lists so we don't
regenerate or download
the same program.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html