** Description changed:
- SDK applications need the following AppArmor policy to run on (at least)
- the Nexus 7:
+ SDK applications need a bunch of hardware specific accesses to graphics
+ devices. Eg, the ubuntu-sdk AppArmor template has:
- /dev/nvmap rw,
- /dev/nvhost-* rw,
- /sys/module/nvhost/parameters/* r,
- /sys/module/fuse/parameters/tegra* r,
+ # FIXME: Nexus7 (grouper)
+ /dev/nvmap rw,
+ /dev/nvhost-* rw,
+ /sys/module/nvhost/parameters/* r,
+ /sys/module/fuse/parameters/tegra* r,
- The read accesses are not ideal but probably ok, but the writes to
- /dev/nvmap and /dev/nvhost-* allow applications to attack these devices
- directly. I'm not sure what the solution is, but the current behavior
- weakens our application confinement policy.
+ # FIXME: Galaxy Nexus specific (maguro)
+ /dev/pvrsrvkm rw,
+
+ # FIXME: Nexus 4 (mako)
+ /dev/kgsl-3d0 rw,
+ /dev/ion rw,
+
+ # FIXME: Nexus 10 (manta)
+ /dev/mali[0-9] rw,
+ /dev/ion rw,
+
+ # FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
+ # so lets avoid that for now. Note, ~/.nv/GLCache is used unless
+ # __GL_SHADER_DISK_CACHE_PATH is set
+ /dev/nvidia[0-9] rw,
+ /dev/nvidiactl rw,
+
+ This is both a maintenance nightmare because the devices don't live
+ under a directory (like we have with /dev/dri/ and /dev/snd) but instead
+ in the toplevel /dev directory (how can we possibly keep track of all
+ the devices?). This also makes porting very difficult because the
+ devices could be anything. Furthermore, the write accesses allow
+ applications to attack these devices directly. The current behavior
+ weakens our application confinement policy as well as making it hard to
+ maintain.
+
+ The best solution would be to have the access to the devices happen via
+ an out of process helper (eg Mir) and use shared memory (or similar,
+ like on Android) to provide access. This type of architecture could also
+ allow for writes but not reads, which could be useful for other things
+ like DRM.
+
+ In the meantime, we could solve the maintenance and ports issue by simply
creating all these devices under a specific directory in /dev, such as
/dev/graphics, and then our apparmor policy would simply have:
+ /dev/graphics/* rw,
** Also affects: lxc-android-config (Ubuntu)
Importance: Undecided
Status: New
** Also affects: lxc-android-config (Ubuntu Saucy)
Importance: Undecided
Status: New
** Also affects: apparmor-easyprof-ubuntu (Ubuntu Saucy)
Importance: Undecided
Status: New
** Changed in: lxc-android-config (Ubuntu Saucy)
Importance: Undecided => High
** Description changed:
SDK applications need a bunch of hardware specific accesses to graphics
devices. Eg, the ubuntu-sdk AppArmor template has:
- # FIXME: Nexus7 (grouper)
- /dev/nvmap rw,
- /dev/nvhost-* rw,
- /sys/module/nvhost/parameters/* r,
- /sys/module/fuse/parameters/tegra* r,
+ # FIXME: Nexus7 (grouper)
+ /dev/nvmap rw,
+ /dev/nvhost-* rw,
+ /sys/module/nvhost/parameters/* r,
+ /sys/module/fuse/parameters/tegra* r,
- # FIXME: Galaxy Nexus specific (maguro)
- /dev/pvrsrvkm rw,
+ # FIXME: Galaxy Nexus specific (maguro)
+ /dev/pvrsrvkm rw,
- # FIXME: Nexus 4 (mako)
- /dev/kgsl-3d0 rw,
- /dev/ion rw,
+ # FIXME: Nexus 4 (mako)
+ /dev/kgsl-3d0 rw,
+ /dev/ion rw,
- # FIXME: Nexus 10 (manta)
- /dev/mali[0-9] rw,
- /dev/ion rw,
+ # FIXME: Nexus 10 (manta)
+ /dev/mali[0-9] rw,
+ /dev/ion rw,
- # FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
- # so lets avoid that for now. Note, ~/.nv/GLCache is used unless
- # __GL_SHADER_DISK_CACHE_PATH is set
- /dev/nvidia[0-9] rw,
- /dev/nvidiactl rw,
+ # FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
+ # so lets avoid that for now. Note, ~/.nv/GLCache is used unless
+ # __GL_SHADER_DISK_CACHE_PATH is set
+ /dev/nvidia[0-9] rw,
+ /dev/nvidiactl rw,
- This is both a maintenance nightmare because the devices don't live
- under a directory (like we have with /dev/dri/ and /dev/snd) but instead
- in the toplevel /dev directory (how can we possibly keep track of all
- the devices?). This also makes porting very difficult because the
- devices could be anything. Furthermore, the write accesses allow
- applications to attack these devices directly. The current behavior
- weakens our application confinement policy as well as making it hard to
- maintain.
+ This is a maintenance nightmare because the devices don't live under a
+ directory (like we have with /dev/dri/ and /dev/snd) but instead in the
+ toplevel /dev directory (how can we possibly keep track of all the
+ devices?). This also makes porting very difficult because the devices
+ could be anything. Furthermore, the write accesses allow applications to
+ attack these devices directly. The current behavior weakens our
+ application confinement policy as well as making it hard to maintain.
The best solution would be to have the access to the devices happen via
an out of process helper (eg Mir) and use shared memory (or similar,
like on Android) to provide access. This type of architecture could also
allow for writes but not reads, which could be useful for other things
like DRM.
In the meantime, we could solve the maintenance and ports issue by simply
creating all these devices under a specific directory in /dev, such as
/dev/graphics, and then our apparmor policy would simply have:
- /dev/graphics/* rw,
+ /dev/graphics/* rw,
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1197133
Title:
SDK applications require hardware-specific direct access to graphics
devices
To manage notifications about this bug go to:
https://bugs.launchpad.net/touch-preview-images/+bug/1197133/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
