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

[John Johansen]

On 05/04/2018 04:59 AM, Jamie Strandboge wrote:
> 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>'
> 
> 
I think we need them split out, whether the original proposal or
Jamie's I'm unsure.

I do think if we go Jamie's route that instead of having pocl
users embed the weirdness we have a pocl abstraction, keeping
the semantic from the beginning is worth it.

On top of each of the opencl-XXX abstractions I think it would
be worth having a generic opencl abstraction that includes
the various sub-abstractions, its wide now but the intent
will be to tighten it up with conditionals once better support
lands.

If someone cares they use the finer abstraction, but the
generic one is there and can just be used for those who just
want opencl to work no matter which system they are on.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180508/48a84148/attachment.sig>