[apparmor] [RFC] How to handle multiple opencl implementations?

[Jamie Strandboge]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180504/53d5298d/attachment.sig>