Re: gnome-sdk update and TODOs
- From: Rob Taylor <rob taylor codethink co uk>
- To: gnome-os-list gnome org
- Subject: Re: gnome-sdk update and TODOs
- Date: Fri, 12 Dec 2014 18:39:50 +0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]