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.
2. Single file, with if-clauses using conditionals:
# if defined $opencl_use_nvidia and $openc_use_nvidia {
# include <abstractions/nvidia>
...
owner @{HOME}/.nv/ComputeCache/index rwk,
...
}
...
# if not defined $opencl_use_nvidia and not defined. .. {
# warning no opencl implementation is selected via opencl_use_X
conditionals
}
3. Just use one single abstraction for all implementations. Maybe
refactor abstraction to organized rules in groups accordingly.
4. ?
For option #2, using conditionals, I guess I should have to wait for
better conditional support in AppArmor? For #3 I could create merge
request just right now (+ maybe some work for refactoring).
So.. any ideas?
Thanks!
* Mesa Clover tested very minimally. It does not work with nouveau fully
yet [3], and I don't own AMD hardware to test alternative. This can be
improved later.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887593#76
[1]
https://gitlab.com/Talkless/apparmor/blob/opencl/profiles/apparmor.d/abstractions/opencl
[2]
https://gitlab.com/Talkless/aatests/blob/master/opencl/usr.local.bin.aatest-opencl.sh
[3] https://github.com/inducer/pyopencl/issues/230#issuecomment-386065202
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
