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>] [day] [month] [year] [list]

Message-ID: <CAADnVQLnXgT4nCJdM9iu77eonAxuEDtPdVMvBJ4Vom_g5Cfb9A@mail.gmail.com>
Date:	Thu, 5 Feb 2015 12:49:35 -0800
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Andy Zhou <azhou@...ira.com>
Cc:	Thomas Graf <tgraf@...ronetworks.com>,
	"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 11:34 AM, Andy Zhou <azhou@...ira.com> wrote:
>>
>> 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.

yes. kinda.
the easiest is just have a flag-like argument in your helper
and as part of the program always pass zero to it initially.
Later when helper function becomes more advanced it will
start interpreting flag argument differently.
pretty much the same concept used everywhere else.

The helper functions need to be thought through
just like any other user interface.

>> 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.

Loading the program as soon as user space got a notification
on flow miss is definitely not efficient and not scalable.
Whereas having already loaded program to be called when
flow-miss happens makes a lot of sense.
In program-as-action proposal there are potentially N number
of programs for N flow rules (unless the same program
is used as action for all rules)
In program-after-flow-miss proposal, there is 1 program per
datapath or may be per-vport (so packets from different VMs
can be processed by different programs)
--
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