Re: Potential issues (security and otherwise) with the current cgroup-bpf API

From
Michal Hocko <mhocko@kernel.org>
Date
2017-01-17 13:24:27
Also in
lkml, netdev
Reply to
Tejun Heo, 2017-01-16
On Sun 15-01-17 20:19:01, Tejun Heo wrote:
[...]
So, what's proposed is a proper part of bpf.  In terms of
implementation, cgroup helps by hosting the pointers but that doesn't
necessarily affect the conceptual structure of it.  Given that, I
don't think it'd be a good idea to add anything to cgroup interface
for this feature.  Introspection is great to have but this should be
introspectable together with other bpf programs using the same
mechanism.  That's where it belongs.
If BPF only piggy backs on top of cgroup to iterate tasks shouldn't we
at least enforce that the cgroup has to be a leaf one and no further
children groups can be created once there is BPF program attached?
This should break the existing usecases AFAIU and it would allow future
changes without major API surprises.

-- 
Michal Hocko
SUSE Labs
Thread (36 messages) 36 messages, 10 authors, last reply 2017-01-19
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help