Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wednesday, 9 May 2018 19:10:13 CEST Mike Gilbert wrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turnerwrote: > > On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
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* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
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"wrote: > > > >>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, 9 May 2018 19:54:16 +0100 "M. J. Everitt"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. pgpcnXCQAAf6Z.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On 09/05/18 19:50, Kent Fredric wrote: > On Wed, 9 May 2018 18:12:32 +0100 > "M. J. Everitt"wrote: > >>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner 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 ... signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, 9 May 2018 18:12:32 +0100 "M. J. Everitt"wrote: > > On Wed, May 9, 2018 at 12:34 PM, Matt Turner 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. pgpcbC695saIi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, May 9, 2018 at 11:43 AM, Matt Turnerwrote: > 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?
On Wed, May 9, 2018 at 10:19 AM, Alec Warnerwrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turner wrote: >> >> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde >> 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?
On Tue, May 8, 2018 at 11:51 PM, Dennis Schriddewrote: > 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?
On Wed, May 9, 2018 at 12:34 PM, Matt Turnerwrote: > On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde > 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
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On 09/05/18 18:10, Mike Gilbert wrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turnerwrote: >> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde 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? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, May 9, 2018 at 12:34 PM, Matt Turnerwrote: > On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde 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?
On Tue, May 8, 2018 at 11:51 PM, Dennis Schriddewrote: > 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?
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?
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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
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
[gentoo-dev] Access to DRM render nodes from portage sandbox?
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 signature.asc Description: This is a digitally signed message part.