Re: gnome-sdk update and TODOs

[Rob Taylor <rob taylor codethink co uk>]

On 11/12/14 10:32, Alexander Larsson wrote:
> On fre, 2014-11-28 at 16:07 +0100, Alexander Larsson wrote:
> > * OpenGL
> >
> >   There is no opengl yet in the base image, and making this work will
> >   be a lot of work, since mesa uses udev and dri devices, relies on
> >   particular kernel/Xorg drivers, etc. It also needs to be replacable
> >   easily as the way you install a different gl driver is to replace the
> >   entire GL library.
> >
> >   Mesa is also pretty unsafe in terms of sandboxing for anything before
> >   DRI3, as DRI2 buffer handles are global and guessable. Dunno about
> >   e.g. nvidia.
> >
> >   This will require a lot of ad-hoc work, and probably some setup to
> >   replace part of a runtime with another sub-runtime.
>
> I've been looking a bit at OpenGL support. The way the mesa (DRI)
> drivers work is that there are device nodes in /dev/dri, which have
> rights such that the user can open them (typically by being in the video
> group, or due to the system setting acls on them for the currently
> logged in user). These nodes are "safe" to expose as they don't give any
> raised privileges on open. Operations that are unsafe generally have to
> be authenticated in some way first.
>
> However, there are still some security issues here. The DRI2 driver APIs
> use global guessable 32bit handles (from gem_flink) for buffers, so
> anyone can read anyones buffers. This is solved with DRI3 which uses fd
> passing instead of int handles.
>
> Obviously, this is kind of uninteresting atm as I'm currently targeting
> X11 apps which is completely unsecure in this sense anyway. However,
> when we later switch to wayland and sandboxing we need to ship *only*
> DRI3 drivers, and assume the host supports these.
>
> To make the drivers work the runtime bind mounts the host /dev/dri into
> the container. This will work for the dri drivers, but I guess we needs
> to also take a look at e.g. the nvidia drivers and the amd drivers to
> see what devices they use, how safe they are to expose, and them mount
> them in too.

I had some discussion with Daniel Stone around this a month back or so.

The vague plan is to add to the wl_drm protocol to pass an FD for the 
rendernode, rather than the DRI card. This should work well for all 
cards with rendernode support, which should be most pretty soon, iirc. 
It also avoids the gem_flink security hole.

I'm hoping to get round to implementing this over the holiday period 
(after nspawn kdbus endpoint support in systemd)

HTH
Rob