On Thu, 2018-05-03 at 20:42 +0300, Vincas Dargis wrote: > Hi, > > Story begins with Debian user reporting issue that LibreOffice is > denied > access to OpenCL related files [0]. > > To fix that I've started to build opencl abstraction. While doing > so, > I've discovered that there are quite a few implementations. At least: > > * POCL (for CPU only I believe) > * Intel Beignet (for Intel graphics) > * Mesa Clover* (for nouveau and AMD) > * NVIDIA (with proprietary driver) > > Current abstraction is found in my GitLab branch [1]. I've been > testing > opencl abstraction with help of > /usr/share/doc/packages/python-pyopencl/examples/demo.py wrapped in > a > script with AppArmor profile [2] from python-pyopencl package > (Debian > Sid, Ubuntu 18.04 and openSUSE Tumbleweed from some non-official > repo). > That demo.py allows to select for OpenCL implementation which helped > a lot. > > Now, the question is, should it be one single abstraction file > dealing > with all and different OpenCL implementations? The question arises > from > the fact that POCL implementation needs to: > > * Execute clang compiler (there's opencl_clang child profile) > * Execute linker (also child profile exists) > * mmap for execution compiled & linked modules from user writable > cache > directories. (!) > > Meanwhile, for the probably first use case of this abstraction, > namely > that LibreOffice profile, POCL is not used, as LibreOffice enables > OpenCL option only when I run it with discrete NVIDIA graphics on my > laptop (it ignores integrated Intel graphics too). So all that POCL > stuff allowed by default is kinda too much for my taste... > > So I wonder, maybe it's worth to let final profile author to select > what > OpenCL implementation should be allowed? > > Possible alternatives: > > 1. Split into multiple abstractions, like: > * opencl-common (probably only /etc/OpenCL/** r, maybe something > else) > * opencl-pocl > * opencl-nvidia > * opencl-whatever. >
Personally I like abstractions to be widely useful provided the permission groupings make sense together and don't introduce anything iffy. I agree with you that some of the POCL stuff sounds iffy. Without seeing the actual rules/denials, what about a variation on the above: * opencl (has intel, mesa, the non-iffy parts of pocl and the non-nvidia parts of opencl-nvidia, etc) * add the nvidia-specific bits of opencl-nvidia to the nvidia abstraction (ie, there is no 'opencl-nvidia' abstraction) * omit opencl-pocl and let pocl users add the weird accesses themselves. *if* this becomes burdensome for people, then perhaps add opencl-pocl that does an '#include <abstractions/opencl>' -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
