1442055 - Tolerate the Primus GPU shim connecting to the Bumblebee daemon while sandboxed

Status: RESOLVED DUPLICATE of bug 1440206

(Core :: Security: Process Sandboxing, enhancement, P1)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

One of the use cases for bug 1440206, and the one that will actively break things if we don't do something about it, is Primus/Bumblebee doing a socket connection when a GL context is created; it will exit the calling process if the connection fails.

First, we need to detect it; the vendor/description/etc. strings it exposes at the OpenGL layer are those of the NVIDIA proprietary driver, but the GLX client vendor string is "primus" instead.  So we'd need to get that string out of the glxtest process and into... something; adding a lot of infrastructure to GfxInfo for this one use case seems suboptimal, but I don't know if there's a simpler alternative.

Second, we need to do something about it; options are:

1. If we can eagerly create the GL context in each content process before starting sandboxing, that should take care of this, but it imposes startup overhead even if WebGL isn't used.

2. We could weaken the sandbox, like with VirtualGL in bug 1438391.

3. We could disable WebGL; this is probably hard to justify.

4. We could move ahead with the connect() brokering in bug 1440206 only for this use case (not the nvidia abstract-namespace socket); this is also somewhat hard to justify given the added attack surface in the broker.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This wound up being handled as part of bug 1440206 after all.