Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[Dennis Schridde <devurandom@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 2827 bytes --]

On Wednesday, 9 May 2018 19:10:13 CEST Mike Gilbert wrote:
> On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@gentoo.org> wrote:
> > On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devurandom@gmx.net> 
wrote:
> >> Hello!
> >> 
> >> I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/
> >> renderD128" pop up for more and more packages, probably since OpenCL
> >> becomes used more widely.  Hence I would like to ask: Could we in Gentoo
> >> treat GPUs just like CPUs and allow any process to access render nodes
> >> (i.e. the GPUs compute capabilities via the specific interface the Linux
> >> kernel's DRM offers for that purpose) without sandbox restrictions?
> >> 
> >> --Dennis
> >> 
> >> See-Also: https://bugs.gentoo.org/654216
> > 
> > This seems like a bad idea. With CPUs we've had decades to work out
> > how to isolate processes and prevent them from taking down the system.
> > 
> > GPUs are not there yet. It's simple to trigger an unrecoverable GPU
> > hang and not much harder to turn it into a full system lock up.
> > 
> > This is not safe.
> 
> It's worth noting that the default rules shipped with udev assign mode
> 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox
> environment, any user may access these devices.
> 
> This was merged as part of this PR:
> https://github.com/systemd/systemd/pull/7112

Also, what's happening right now is that every ebuild that *does* somehow use 
DRM render nodes receives SANDBOX_PREDICT or SANDBOX_WRITE access to them.

And the cycle is usually:
* Bump into a usage of render nodes that breaks the build at the very end
* Report a bug
* Wait
* The ebuild gets "allow access to the first render node" code added
* Someone with 2 GPUs runs into the same issue for the second render node
* ... rinse and repeat ...
* Eventually, after enough people ran into it, the ebuild gets its own custom
  "find all render nodes and allow access" code added

Additionally it appears that often the usage is indirect, through another tool 
or library.  So for ebuild developers this is not really predictable.

Thus at the very least I would suggest adding code this code (to allow access 
to all render nodes) to an eclass, so it is easier for ebuild developers to 
fix their ebuild properly, once and for all.

But by then the process is so easy and already so many builds are using render 
nodes, that the surface for builds to take down the system is very high.  If 
the chromium build (e.g.) could trigger a bug in Mesa that takes down the 
system, so could anyone else.  And if we trust their toolchain (and with a 
build time of several hours, I believe this to be a large set of tools and a 
lot of code) to not bring down the system, without a complete audit or 
something of the sort, why don't we trust anyone else?

--Dennis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]