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

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

[Dennis Schridde]

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

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

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

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

[Michał Górny]

W dniu śro, 09.05.2018 o godzinie 08∶51 +0200, użytkownik Dennis
Schridde napisał:
> 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

Doesn't accessing those nodes involve a risk of programs being able to
crash your system (or xorg)?  Or cause on-screen artifacts?

-- 
Best regards,
Michał Górny

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

[Dennis Schridde]

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

On Wednesday, 9 May 2018 09:34:43 CEST Michał Górny wrote:
> W dniu śro, 09.05.2018 o godzinie 08∶51 +0200, użytkownik Dennis
> 
> Schridde napisał:
> > 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?
> > 
> > See-Also: https://bugs.gentoo.org/654216
> 
> Doesn't accessing those nodes involve a risk of programs being able to
> crash your system (or xorg)?  Or cause on-screen artifacts?

Well, in the presence of Linux kernel bugs, programs could crash the whole 
system.  But I believe this is also true for all other drivers and compute 
devices, including CPUs.

I assume an application using render nodes could crash X by e.g. consuming all 
memory.  But then this is also true for all applications using the CPU and its 
attached memory for computations.

On-screen artifacts as in resolution switching and other KMS operations is 
explicitly prohibited.  Insecure access (using GEM FLINK) to the memory of 
other applications (which could cause broken textures / windows with broken 
content) is also explicitly prohibited.  So my understanding is that the 
answer is: No, using render nodes cannot cause on-screen artifacts (modulo the 
presence of Linux kernel bugs, s.a.).

DRM render nodes were specifically introduced to allow GPGPU applications to 
run without impacting the security of the system (and without X).

The Linux kernel documentation contains some information on the concept:
* https://www.kernel.org/doc/html/v4.16/gpu/drm-uapi.html#render-nodes

As well as an older blog post by David Herrmann:
* https://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/

And the Wikipedia article on DRM:
* https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes

--Dennis

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

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

[Michał Górny]

W dniu śro, 09.05.2018 o godzinie 09∶56 +0200, użytkownik Dennis
Schridde napisał:
> On Wednesday, 9 May 2018 09:34:43 CEST Michał Górny wrote:
> > W dniu śro, 09.05.2018 o godzinie 08∶51 +0200, użytkownik Dennis
> > 
> > Schridde napisał:
> > > 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?
> > > 
> > > See-Also: https://bugs.gentoo.org/654216
> > 
> > Doesn't accessing those nodes involve a risk of programs being able to
> > crash your system (or xorg)?  Or cause on-screen artifacts?
> 
> Well, in the presence of Linux kernel bugs, programs could crash the whole 
> system.  But I believe this is also true for all other drivers and compute 
> devices, including CPUs.
> 
> I assume an application using render nodes could crash X by e.g. consuming all 
> memory.  But then this is also true for all applications using the CPU and its 
> attached memory for computations.
> 
> On-screen artifacts as in resolution switching and other KMS operations is 
> explicitly prohibited.  Insecure access (using GEM FLINK) to the memory of 
> other applications (which could cause broken textures / windows with broken 
> content) is also explicitly prohibited.  So my understanding is that the 
> answer is: No, using render nodes cannot cause on-screen artifacts (modulo the 
> presence of Linux kernel bugs, s.a.).
> 
> DRM render nodes were specifically introduced to allow GPGPU applications to 
> run without impacting the security of the system (and without X).
> 

Ok then.  I suppose I was confusing it with /dev/nvidia*.

-- 
Best regards,
Michał Górny

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

[Matt Turner]

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.

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

[Mike Gilbert]

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

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

On 09/05/18 18:10, 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
>
How does that pan out for other init systems?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Alec Warner]

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

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.
>
>
Is the sandbox considered a security boundary? Certainly in earlier
(LD_PRELOAD based) implementation it was not.
Instead it was intended to protect the build environment from leaks (e.g.
accessing unwanted host state in the build env.)

Sure it also in theory prevented build environments from writing to the
host; but it didn't do a very secure job of it.

-A

[-- Attachment #2: Type: text/html, Size: 2142 bytes --]

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

[Matt Turner]

On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devurandom@gmx.net> wrote:
> 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.

I want to respond to the mention of OpenCL being more widely used...

https://www.x.org/wiki/Events/XDC2017/Program/#tomstellardredhat-currentstateofopensourcegpgpu

In short, the state of OpenCL in general is bad. On top of that, many
of the implementations we have in Gentoo are unmaintained, despite my
repeated requests of interested parties.

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

[Matt Turner]

On Wed, May 9, 2018 at 10:19 AM, Alec Warner <antarus@gentoo.org> 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.
>>
>
> Is the sandbox considered a security boundary? Certainly in earlier
> (LD_PRELOAD based) implementation it was not.
> Instead it was intended to protect the build environment from leaks (e.g.
> accessing unwanted host state in the build env.)
>
> Sure it also in theory prevented build environments from writing to the
> host; but it didn't do a very secure job of it.

I don't know.

Irrespective to the answer to that question, it's my opinion that we
should not execute code via the package manager that has the potential
to bring down the whole system.

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

[Matt Turner]

On Wed, May 9, 2018 at 11:43 AM, Matt Turner <mattst88@gentoo.org> wrote:
> Irrespective to the answer to that question, it's my opinion that we
> should not execute code via the package manager that has the potential
> to bring down the whole system.

... and if anyone doubts that possibility, please do a full piglit [1]
run before you reply.

[1] https://cgit.freedesktop.org/piglit/

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

[Kent Fredric]

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

On Wed, 9 May 2018 18:12:32 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> > On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@gentoo.org> wrote:  
> > 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
> >  
> How does that pan out for other init systems?

udev

Which practically everyone uses regardless of init system. Even openrc users.

Upstream, udev is part of systemd now.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1084 bytes --]

On 09/05/18 19:50, Kent Fredric wrote:
> On Wed, 9 May 2018 18:12:32 +0100
> "M. J. Everitt" <m.j.everitt@iee.org> wrote:
>
>>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@gentoo.org> wrote:  
>>> 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
>>>  
>> How does that pan out for other init systems?
> udev
>
> Which practically everyone uses regardless of init system. Even openrc users.
>
> Upstream, udev is part of systemd now.
^ That is relatively common knowledge .. my question was more steered
towards whether Eudev is carrying this feature through as well (which
likely as they might ... ) I believe eudev was voted to become the
default implementation for Gentoo, to complement openRC as it was
becoming impossible to maintain udev-standalone separate from systemd.

Do correct me if I'm mistaken ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Kent Fredric]

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

On Wed, 9 May 2018 19:54:16 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> Do correct me if I'm mistaken ...

Right, just the statement of:

 "I wonder how that pans out for other init systems"

Understandably introduces some confusion, when udev is not an init
system, and is frequently used in conjunction with one ;)

... either by using the systemd backed version, or our systemd-free
fork.

And out fork pretty much replicates changes from systemd:


https://github.com/gentoo/eudev/commit/bb070c154e7064c752b13a4f84ecad9201a2f460

However, unlike the systemd side where the definition of
GROUP_RENDER_MODE is clear:
https://github.com/systemd/systemd/pull/7112/files#diff-f2ff94c68cbdd606743b339aa68a4164

How that value gets assigned on eudev is not at all clear.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[William Hubbs]

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

On Wed, May 09, 2018 at 07:54:16PM +0100, M. J. Everitt wrote:
> On 09/05/18 19:50, Kent Fredric wrote:
> > On Wed, 9 May 2018 18:12:32 +0100
> > "M. J. Everitt" <m.j.everitt@iee.org> wrote:
> >
> >>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@gentoo.org> wrote:  
> >>> 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
> >>>  
> >> How does that pan out for other init systems?
> > udev
> >
> > Which practically everyone uses regardless of init system. Even openrc users.
> >
> > Upstream, udev is part of systemd now.
> ^ That is relatively common knowledge .. my question was more steered
> towards whether Eudev is carrying this feature through as well (which
> likely as they might ... ) I believe eudev was voted to become the
> default implementation for Gentoo, to complement openRC as it was
> becoming impossible to maintain udev-standalone separate from systemd.

Well, it is not impossible to maintain udev standalone, we are still
doing it just fine, so if that is the reason eudev was made the default,
we need to revisit that. Not in this thread, however.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 829 bytes --]

On 09/05/18 20:31, William Hubbs wrote:
> On Wed, May 09, 2018 at 07:54:16PM +0100, M. J. Everitt wrote:
>> ^ That is relatively common knowledge .. my question was more steered
>> towards whether Eudev is carrying this feature through as well (which
>> likely as they might ... ) I believe eudev was voted to become the
>> default implementation for Gentoo, to complement openRC as it was
>> becoming impossible to maintain udev-standalone separate from systemd.
> Well, it is not impossible to maintain udev standalone, we are still
> doing it just fine, so if that is the reason eudev was made the default,
> we need to revisit that. Not in this thread, however.
>
> William
Probably over-simplified there a little.

Still, I think we've run round one loop, and still not learnt much new...
*fakes surprise*


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Dennis Schridde]

[-- 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 --]