Re: [PATCH net-next 4/7] ebpf: extend program type/subsystem registration

On Tue, Feb 10, 2015 at 4:15 PM, Daniel Borkmann [off-list ref] 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...

On 02/11/2015 02:37 AM, Alexei Starovoitov wrote:
...

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.

Right, I share this concern. That requires to make helper functions
generic enough and shareable among various ebpf users, but that should
be possible, so as mentioned in the other mail, the cls program type
reusing sock_filter_ops is a good way forward.

Thanks for the review!