[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMEtUuxwdk8RDbUbo8SO9zMU2ELgf-xZynEeT5i5JBNLc2Y_Hw@mail.gmail.com>
Date: Tue, 10 Feb 2015 17:37:17 -0800
From: Alexei Starovoitov <ast@...mgrid.com>
To: Daniel Borkmann <daniel@...earbox.net>, Thomas Graf <tgraf@...g.ch>
Cc: Jiří Pírko <jiri@...nulli.us>,
Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 4/7] ebpf: extend program type/subsystem registration
On Tue, Feb 10, 2015 at 4:15 PM, Daniel Borkmann <daniel@...earbox.net> wrote:
> When various subsystems/modules start to make use of ebpf
> e.g. cls_bpf, act_bpf, ovs, ... we need to make sure, they
> can register their program types only once.
>
> Moreover, we also need to serialize various registrations,
> currently program type registration is being done without
> locks. (We should make sure to not race in future when we
> allow registration from modules.)
>
> Last but not least, we need to be able to register subsystems
> from module context as it's not sufficient to have them only
> as built-in at all time.
imo that is scary. there is no unregister_type by design,
since I didn't want modules to use bpf.
My concern that if we allow modules to register new program
types we allow bypass of gpl and all safety checks we've
put in place.
Modules will define whatever helper functions they like.
We won't be able to control or even code review this stuff.
I think all types and all helper functions should be built-in.
This way we know what bpf is used for and that it's not abused.
Yes, having all types and helpers built-in creates
some challenges for ovs and tc, but I think it's much
safer long term.
I think for networking one or two prog types will be enough
and hopefully ovs/tc/... will settle on common set of helpers.
'bpf for modules' was one of the topics I wanted to
discuss at netdev01. Looks like we started it early...
--
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
Powered by blists - more mailing lists