1 |
On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@g.o> wrote: |
2 |
|
3 |
> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devurandom@×××.net> |
4 |
> wrote: |
5 |
> > Hello! |
6 |
> > |
7 |
> > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ |
8 |
> > renderD128" pop up for more and more packages, probably since OpenCL |
9 |
> becomes |
10 |
> > used more widely. Hence I would like to ask: Could we in Gentoo treat |
11 |
> GPUs |
12 |
> > just like CPUs and allow any process to access render nodes (i.e. the |
13 |
> GPUs |
14 |
> > compute capabilities via the specific interface the Linux kernel's DRM |
15 |
> offers |
16 |
> > for that purpose) without sandbox restrictions? |
17 |
> > |
18 |
> > --Dennis |
19 |
> > |
20 |
> > See-Also: https://bugs.gentoo.org/654216 |
21 |
> |
22 |
> This seems like a bad idea. With CPUs we've had decades to work out |
23 |
> how to isolate processes and prevent them from taking down the system. |
24 |
> |
25 |
> GPUs are not there yet. It's simple to trigger an unrecoverable GPU |
26 |
> hang and not much harder to turn it into a full system lock up. |
27 |
> |
28 |
|
29 |
> This is not safe. |
30 |
> |
31 |
> |
32 |
Is the sandbox considered a security boundary? Certainly in earlier |
33 |
(LD_PRELOAD based) implementation it was not. |
34 |
Instead it was intended to protect the build environment from leaks (e.g. |
35 |
accessing unwanted host state in the build env.) |
36 |
|
37 |
Sure it also in theory prevented build environments from writing to the |
38 |
host; but it didn't do a very secure job of it. |
39 |
|
40 |
-A |