Classic confinement for clpeak

store-requests
1

Clpeak is a synthetic benchmarking tool to measure peak capabilities of opencl devices

This opencl application cannot find all opencl platforms in strict confinement. I did try adding opengl as a plug, but that exposed only 1 platform.

For eg., I have 5 different opencl platforms installed on my host machine in different locations. When this app is run with opengl plug in strict confinement, only 1 platform i.e nvidia gets listed. For all the platforms to be visible in the app, it needs access to all files mentioned in /etc/OpenCL/vendors/, which will be available only in classic confinement.

So, hereby requesting classic confinement for clpeak

2

While I understand you want to get your snap working, I’d like to get clarification on the record as to whether the interfaces can be extended to encompass your requirements. Specifically you mention the /etc/OpenCL folder, which we might consider to add into either the opengl interface or a new opencl interface.

1 Like
3

Thats good to hear.
The spec says every icd file in /etc/OpenCL/vendors/ contains the name of shared-object of the platform driver. It could be a filename or absolute path.

Eg.

/etc/OpenCL/vendors/intel64.icd => /opt/intel/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libintelocl.so
/etc/OpenCL/vendors/intel-beignet-x86_64-linux-gnu.icd => /usr/lib/x86_64-linux-gnu/beignet//libcl.so
/etc/OpenCL/vendors/intel.icd => /usr/local/lib/libigdrcl.so
/etc/OpenCL/vendors/nvidia.icd => libnvidia-opencl.so.1
/etc/OpenCL/vendors/pocl.icd => /usr/local/lib/libpocl.so.2.3.0

So all these .so files & their dependent files needs to be available in app’s filesystem. I guess it might be difficult to figure out all the dependencies of a platform driver

4

I’m inclined to update existing interfaces for this as well, but see that the shared libraries are sprinkled all over the place. I suspect that you will have trouble making a classic snap work in a robust manner across all the supported distributions with things working like this. It seems that for typical OpenCL usage we’d want to grant access to /etc/OpenCL/{,**} r, and expand opengl to handle the libs in /usr/lib. Can you comment on that for the general case? I understand for your snap, this wouldn’t work.

@zyga-snapd - can you participate in this conversation?

5

I guess something has already been done about opencl in opengl plug https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support-nvidia.c#L114 and https://github.com/snapcore/snapd/blob/master/interfaces/builtin/opengl.go#L86 , which is why I can see only nvidia platform in strict mode when plugged with opengl. This should be sufficient for apps needing only gpu

6

Ping @zyga-snapd - interested on your thoughts on this before proceeding.

7

This is an interesting case.

@kraj03 would you mind sharking the information in /etc/OpenCL/vendors/? Would you mind running the software (e.g. packaged with classic confinement) via strace to let us see what kind of access is really taking place?

Personally I’d be okay with granting the request until the time that snapd improves enough to model this system sufficiently for this to become strict. In addition the open-ended nature of the OpenCL plugin system means that depending on the actual hardware the set of sandbox changes will change.

8

Trimmed strace logs for both cases

Classic:

openat(AT_FDCWD, “/etc/OpenCL/vendors/nvidia.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel-beignet-x86_64-linux-gnu.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel64.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/pocl.icd”, O_RDONLY) = 4

openat(AT_FDCWD, “/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1”, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, “/usr/local/lib/libigdrcl.so”, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, “/usr/lib/x86_64-linux-gnu/beignet//libcl.so”, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, “/opt/intel/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libintelocl.so”, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, “/usr/local/lib/libpocl.so.2.3.0”, O_RDONLY|O_CLOEXEC) = 4

Strict with opengl plug:

openat(AT_FDCWD, “/etc/OpenCL/vendors/nvidia.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel-beignet-x86_64-linux-gnu.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/intel64.icd”, O_RDONLY) = 4
openat(AT_FDCWD, “/etc/OpenCL/vendors/pocl.icd”, O_RDONLY) = 4

openat(AT_FDCWD, “/var/lib/snapd/lib/gl/libnvidia-opencl.so.1”, O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, “/usr/local/lib/libigdrcl.so”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, “/usr/lib/x86_64-linux-gnu/beignet//libcl.so”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, “/opt/intel/opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libintelocl.so”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, “/usr/local/lib/libpocl.so.2.3.0”, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

While /etc/OpenCL/vendors/ is accessible in both cases, the other 4 platform driver files(apart from nvidia) are not visible in strict case, which is expected due to confinement

1 Like
9

Thank you for providing the information so far.

Can you expand on how you procured the files installed under /opt and /usr/local. I understand those are third party packages. It is my understanding that to participate in the snap world those would need to become snaps that expose a content interface with the appropriate libraries.

I will add a note that I’m worried about the situation in /etc. It is my belief that the original decision to expose the host’s /etc directory was a mistake and that the cost of fixing that mistake will be long and complex migration path for existing software packages.

In case snapd models openCL drivers, we could synthesise an appropriate /etc directory content but in our current situation that is difficult.

10

Driver in /opt was downloaded from intel site and installed, and the ones in /usr/local were locally built & installed from opensource projects

In case snapd models openCL drivers, we could synthesise an appropriate /etc directory content but in our current situation that is difficult.

I get it. This will be a difficult task

11

Would both the intel driver and the locally-built driver work inside a snap context? That is, do they depend on access to hardware that is mediated by the snapd sandbox?

12

As mentioned on IRC, I’m not sure about that assessment (there are benefits to using the global /etc as well), but it is clear this is something that is thorny (and I’d hate to swap one set of thorny problems for another without a crystal clear understanding of the new set of thorny problems).

That said, it seems plausible we could use bind mounts for /etc/OpenCL to present a consistent view of this to all snaps.

13

@jdstrand note that global etc largely doesn’t matter because only a subset govern by interfaces can be actually read. I still assert that it would be much easier to use an empty tmpfs etc and add things rather than figure out the complexities of merging things. Adding a bind mount when the mount point is absent on the host (or is of different inode type) is complex.

14

@kraj03 - this request cannot proceed without the requested information.

15

They do work properly in classic context. In case of strict, since they don’t get detected in first place, I won’t know

16

No news, guys? I’m interested in “clpeak”, it’d be a great tool to have.

17

@zyga-snapd - is there more information you need?

18

@zyga-snapd - can you comment on if there is anything else you need?

19

Ping @zyga-snapd - can you comment if there is anything else you need?

20

I’m sorry, my mind was focused on other tasks. I will review this and amend this comment.

EDIT:

I’d like to see clpeak available in the snap store. We have some work that might eventually support a fully confined version with no compromises but it should not be in the way of utility.

1 Like