Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 5, 2013 18:28 UTC (Thu) by jspaleta (subscriber, #50639)
In reply to: Another daemon for managing control groups by rvfh
Parent article: Another daemon for managing control groups

I'm actually having a hard time finding a publicly archived discussion over a deficiency in the systemd API. I've even gone back to the lkml cgroup status quo thread starting Mayish 2013.

I'm not seeing an on-the-record deficiency or summary analysis of why the systemd cgroup management API is unusable.

It'll be interesting to see how different the alternative spec ends up being. But so far its just a draft spec its its literally half a year of inaction on even starting to draft an alternative spec.

It's still not clear to me that the lxc/ubuntu/google contigency have an understanding of the security issues manifest in multiple manager approach. Tejun has tried to explain the problem several times now in the archived discussion channels. First in the lkml and in the lxc-devel discussion..kickstarted by the vUDS session. It's just not clear to me that the leads in the alternative management effort understand why a single manager is needed at all. Nor do I think perhaps everyone in that camp gets how deeply dynamic device management can be now in very real world situations.

It sort of feels like they've been blindsided a bit...hit by the accelerating bus of kernel development which, last time they looked up to watch its progress, appeared to be miles away and moving slow. They put their head back down and..blam...runover as its picked up speed while they were not paying attention.

Don't fall into the trap on focusing on Lennart's contributions to the discussion. The real meat of the discussion is the discussion between Tejun, Tim and Serge as it spans the workman-devel list lkml in May/June and now in the lxc-devel list. The real discussion is the back and forth there as Tejun tries to explain why the new kernel API is being stood up. I don't see how in the world systemd and the yet to be built alternative are going to agree on an API, when the team building the alternative can't seem to understand why the kernel side needs to rely on a userspace with single manager (regardless of what that is). If they don't get the reasons, they won't built a solution that solves the security problems and the API will look crazy different as a result.

Honestly, Tejun is bending over backwards to be diplomatic and to try to explain things..repeatedly. It just doesn't seem to have sunk in. Oh well.

-jef

to post comments

Another daemon for managing control groups

Posted Dec 5, 2013 21:42 UTC (Thu) by jubal (subscriber, #67202) [Link] (6 responses)

Are you trying to say that Tim Hockin does not have any idea what cgroups are and how they should be managed, Jef?

(BTW, Lennart, nice hissy fit both here and on your g+ account, additional ten points for class.)

Another daemon for managing control groups

Posted Dec 5, 2013 22:35 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (2 responses)

No I'm saying he may not fully understand why the cgroup interface is being reworked because Google's internal use case don't need to consider the security issues Tejun is looking to solve by very deliberately cutting out functionality Tim is currently relying on.

The workman-devel list archived communication in June and July between Tejun and Tim really captures the meat of the dispute. Tim was blindsided by the speed at which systemd's implementation of a manager matured to meet the kernel side development of the new interface. And even though Tejun tries to explain why the kernel interface changes are happening, I never get the feeling Tim understands what Tejun is attempting to communicate. Tim's unhappy that the single heiarchy change is going to land on the kernel side. Tim is unhappy that the new kernel interface is taking away flexibility his use case currently relies on. The kernel side change is coming, regardless of systemd's high level implementation decision on how to deal with that inbound kernel change. It's coming. Tim admits Google already has an in-production in-house developed high level API for cgroup management in some form (oh the irony of that!)

The fact that systemd has a mature implementation of a cgroup manager API for the new kernel interface with kernel dev side buy-in is germane to Tim's core concern only because the maturity of that implementation means he potentially has less time to ignore the new kernel interface and to deal with adapting Google's in-house uncollaboratively developed tooling, by spinning up an alternative implementation to meet the requirements of the new cgroups interface. Even though Tejun diffuses this concern to some degree by stating the older, less secure interface will still be there, and Google should be able to continue running as is.

Thought out the entire discussion Tim's concern is still primarily about the collapse of the multi-hierarchy which Google's use case depends on and the requirement of having a central manager. Tim really doesn't care what systemd is doing as a high level API to wrap the kernel interface. Google isn't going to use it. Google is happy with their in-house tools.

There is a lot to chew on in that workman-devel thread... just in the discussion between Tejun and Tim and ignoring all other discussion. I'm left seriously wondering if Tim really understands and appreciates the security issues Tejun is attempting to solve with the new cgroups interface.

Tejun is serious about cleaning up the cgroup interface. Seriously serious.
The more people start pushing back about the proposed kernel side adjustments with details of how it breaks their use case, the more Tejun's concerns make sense to me from a security persepctive. People are doing some crazy crazy things with cgroups.

Another daemon for managing control groups

Posted Dec 5, 2013 22:53 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

I tried to read the thread and it seems like Tim never explained exactly why they can't do what they want with a single hierarchical structure and Tejun never explained in a understandable way the exact reasons why they cannot maintain a multi-hierarchical interface.

Although you are right that systemd has absolutely nothing to do with it. They'd have the same problem regardless of what method they use to manage cgroups.

Another daemon for managing control groups

Posted Dec 5, 2013 23:23 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

Indeed,

I actually think it was surprising at how quickly systemd spun up a working manager interface. Tejun started this particular ball rolling in Feb/March 2012. LWN covered it. I think a lot of people, who should have been aware of Tejun's plans, just assumed it would take more time for anyone to spin up a working manager implementation for the saner cgroups interface he's spinning up.

The fact systemd that did it this quickly, I think speaks volumes.

The fact that everyone else sat on their hands for a year+ after Tejun's decision also speaks volumes.

Tejun is serious about cleaning up the lawless wild west. I'm not sure enough people took him seriously until systemd landed its public implementation. But really, a year later after Tejun stated his firm intention to move forward and you want to finally start to engage and push back? Meh.

-jef

Another daemon for managing control groups

Posted Dec 6, 2013 1:03 UTC (Fri) by ovitters (guest, #27950) [Link] (2 responses)

(BTW, Lennart, nice hissy fit both here and on your g+ account, additional ten points for class.)

If you don't like someone responding in a certain way, don't be an ass yourself ("nice hissy fit, additional ten points for class").

Another daemon for managing control groups

Posted Dec 6, 2013 14:21 UTC (Fri) by jubal (subscriber, #67202) [Link] (1 responses)

There's a difference between sarcasm and hissy fits.

Another daemon for managing control groups

Posted Dec 10, 2013 9:03 UTC (Tue) by mp (subscriber, #5615) [Link]

Pretty insignificant compared to the similarity in what they do to advance the discussion.