ubuntu-phonedations-bugs team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

** 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: 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 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 in a couple of ways:
  1. 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,
  
  2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
  ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"
  
  which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
-   /dev/kgsl-3d0 rw,
+   /dev/kgsl-3d0 rw,
  
- This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have 
+ This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
  /etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed.
+ 
+ 3. is a variation on '2' except rather than using udev RUN to generate
+ the policy, the package that ships the udev rule will ship corresponding
+ apparmor policy to drop into  /etc/apparmor.d/abstractions/hardware/
+ somewhere.

-- 
You received this bug notification because you are a member of Ubuntu
Phonedations bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/1197133

Title:
  SDK applications require hardware-specific direct access to graphics
  devices

Status in Touch Preview Images:
  New
Status in “apparmor-easyprof-ubuntu” package in Ubuntu:
  Triaged
Status in “lxc-android-config” package in Ubuntu:
  Confirmed
Status in “apparmor-easyprof-ubuntu” source package in Saucy:
  Triaged
Status in “lxc-android-config” source package in Saucy:
  Confirmed

Bug description:
  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: 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 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 in a couple of ways:
  1. 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,

  2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
  ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"

  which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
    /dev/kgsl-3d0 rw,

  This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
  /etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed.

  3. is a variation on '2' except rather than using udev RUN to generate
  the policy, the package that ships the udev rule will ship
  corresponding apparmor policy to drop into
  /etc/apparmor.d/abstractions/hardware/ somewhere.

To manage notifications about this bug go to:
https://bugs.launchpad.net/touch-preview-images/+bug/1197133/+subscriptions