On 09/22/2016 05:12 PM, Daniel Borkmann wrote:

On 09/22/2016 02:05 PM, Pablo Neira Ayuso wrote:

quoted

Benefits are, rewording previous email:

* You get access to all of the existing netfilter hooks in one go
   to run bpf programs. No need for specific redundant hooks. This
   provides raw access to the netfilter hook, you define the little
   code that your hook runs before you bpf run invocation. So there
   is *no need to bloat the stack with more hooks, we use what we
   have.*

But also this doesn't really address the fundamental underlying problem
that is discussed here. nft doesn't even have cgroups v2 support, only
xt_cgroups has it so far, but even if it would have it, then it's still
a scalability issue that this model has over what is being proposed by
Daniel, since you still need to test linearly wrt cgroups v2 membership,
whereas in the set that is proposed it's integral part of cgroups and can
be extended further, also for non-networking users to use this facility.
Or would the idea be that the current netfilter hooks would be redone in
a way that they are generic enough so that any other user could make use
of it independent of netfilter?

Yes, that part I don't understand either.

Pablo, could you outline in more detail (in terms of syscalls, commands,
resulting nftables layout etc) how your proposed model would support
having per-cgroup byte and packet counters for both ingress and egress,
and filtering at least for ingress?

And how would that mitigate the race gaps you have been worried about,
between cgroup creation and filters taking effect for a task?


Thanks,
Daniel