<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman <span dir="ltr">&lt;<a href="mailto:gregkh@linuxfoundation.org" target="_blank">gregkh@linuxfoundation.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:<br>

&gt; So the big issues for a device namespace to solve are filtering which<br>
&gt; devices a container has access to and being able to dynamically change<br>
&gt; which devices those are at run time (aka hotplug).<br>
<br>
</div>As _all_ devices are hotpluggable now (look, there&#39;s no CONFIG_HOTPLUG<br>
anymore, because it was redundant), I think you need to really think<br>
this through better (pci, memory, cpus, etc.) before you do anything in<br>
the kernel.<br>
<div><br>
&gt; After having thought about this for a bit I don&#39;t know if a pure<br>
&gt; userspace solution is sufficient or actually a good idea.<br>
&gt;<br>
&gt; - We can manually manage a tmpfs with device nodes in userspace.<br>
&gt;   (But that is deprecated functionality in the mainstream kernel).<br>
<br>
</div>Yes, but I&#39;m not going to namespace devtmpfs, as that is going to be an<br>
impossible task, right?<br></blockquote><div><br></div><div>That sounds like a challenge ;-)</div><div>Seriously, as Serge correctly noted, it would not be that different from devpts</div><div>if you start from an empty devtmpfs and populate it with devices that are &quot;added</div>
<div>in the context of that namespace&quot;.</div><div>The semantics in which devices are &quot;added in the context of a namespace&quot;</div><div>is the missing piece of the puzzle.</div><div><br></div><div>What we really like to see is a setns() style API that can be used to</div>
<div>add a device in the context of a namespace in either a &quot;shared&quot; or &quot;private&quot;</div><div>mode.</div><div>This kind of API is a required building block for us to write device drivers</div><div>that are namespace aware in a way that userspace will have enough flexibility</div>
<div>for dynamic configuration.</div><div><br></div><div>We are trying to come up with a proposal for that sort of API.</div><div>When we have something decent, we shall post it.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
And remember, udev doesn&#39;t create device nodes anymore...<br>
<div><br>
&gt; - We can manually export a subset of sysfs with bind mounts.<br>
&gt;   (But that feels hacky, and is essentially incompatible with hotplug).<br>
<br>
</div>True.<br>
<div><br>
&gt; - We can relay a call of /sbin/hotplug from outside of a container<br>
&gt;   to inside of a container based on policy.<br>
&gt;   (But no one uses /sbin/hotplug anymore).<br>
<br>
</div>That&#39;s right, they should be listening to libudev events, so why can&#39;t<br>
your daemon shuffle them off to the proper container, all in userspace?<br>
<div><br>
&gt; - There is no way to fake netlink uevents for a container to see them.<br>
&gt;   (The best we could do is replace udev everywhere with something that<br>
&gt;    listens on a unix domain socket).<br>
<br>
</div>You shouldn&#39;t need to do this.<br>
<div><br>
&gt; - It would be nice to replace the device cgroup with a comprehensive<br>
&gt;   solution that really works. (Among other things the device cgroup<br>
&gt;   does not work in terms of struct device the underlying kernel<br>
&gt;   abstraction for devices).<br>
<br>
</div>I didn&#39;t even know there was a device cgroup.<br>
<br>
Which means that if there is one, odds are it&#39;s useless.<br>
<div><br>
&gt; We must manage sysfs entries as well device nodes because:<br>
&gt; - Seeing more than we should has the real potential to confuse<br>
&gt;   userspace, especially a userspace that replays uevents.<br>
<br>
</div>You should never replay uevents.  If you don&#39;t do that, why can&#39;t you<br>
see all of sysfs?<br>
<div><br>
&gt; - Some device control must happens through writing to sysfs files and<br>
&gt;   if we don&#39;t remove all root privileges from a container only by<br>
&gt;   exporting a subset of sysfs to that container can we limit which<br>
&gt;   sysfs nodes can be written to.<br>
<br>
</div>But you have the issue of controlling devices in a &quot;shared&quot; way, which<br>
isn&#39;t going to be usable for almost all devices.<br>
<div><br>
&gt; The current kernel tagged sysfs entry support does not look like a good<br>
&gt; match for the impelementing device filtering.   The common case will<br>
&gt; be allowing devices like /dev/zero, and /dev/null that live in<br>
&gt; /sys/devices/virtual and are the devices we are most likely to care<br>
&gt; about.  Those devices need to live in multiple device namespaces so<br>
&gt; everyone can use them.  Perhaps exclusive assignment will be the more<br>
&gt; common paradigm for device namespaces like it is for network devices in<br>
&gt; the network namespace but from what little I can of this problem right now I<br>
&gt; don&#39;t think so.<br>
&gt;<br>
&gt; I definitely think we should hold off on a kernel level implementation<br>
&gt; until we really understand the issues and are ready to implement device<br>
&gt; namespaces correctly.<br>
<br>
</div>I agree, especially as I don&#39;t think this will ever work.<br>
<div><br>
&gt; A userspace implementation looks like it can only do about 95% of what<br>
&gt; is really needed, but at the same time looks like an easy way to<br>
&gt; experiment until the problem is sufficiently well understood.<br>
<br>
</div>95% is probably way better than what you have today, and will fit the<br>
needs of almost everyone today, so why not do it?<br>
<br>
I&#39;d argue that those last 5% either are custom solutions that never get<br>
merged, or candidates for true virtulization.<br>
<div><br>
&gt; In summary the situation with device hoptlug and containers sucks today,<br>
&gt; and we need to do something.  Running a linux desktop in a container is<br>
&gt; a reasonably good example use case.<br>
<br>
</div>No it isn&#39;t.  I&#39;d argue that this is a horrible use case, one that you<br>
shouldn&#39;t do.  Why not just use multi-head machines like people do who<br>
really want to do this, relying on user separation?  That&#39;s a workable<br>
solution that is quite common and works very well today.<br>
<div><br>
&gt; Having one standard common maintainable implementation would be very<br>
&gt; useful and the most logical place for that would be in the kernel.<br>
&gt; For now we should focus on simple device filtering and hotplug.<br>
<br>
</div>Just listen for libudev stuff, don&#39;t try to filter them, or ever<br>
&quot;replay&quot; them, that way lies madness, and lots of nasty race conditions<br>
that is guaranteed to break things.<br>
<br>
good luck,<br>
<br>
greg k-h<br>
</blockquote></div><br></div></div>