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@g.o> wrote:
> On Wed, May 9, 2018 at 12:34 PM, Matt Turner <mattst88@g.o> wrote:
>>
>> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde <devurandom@×××.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.