integration with vc4 DRM driver

[anholt]

Have you considered integration with the vc4 kernel driver for dispatching your CL jobs? It could expose a root-only ioctl taking the start pointers and count and trusting the user. I've got some old code at https://github.com/anholt/linux/commits/rpi-4.4.y-qpu-execute that needed a user.

The other question I have is: For VC4 I was able to make my compiler emit code in such a way that the kernel could verify that we didn't exceed buffer bounds for a given set of buffers with a particular shader (texture samplers have a descriptor, uniform array access gets clamping on the addresses, uniform stream gets reset at branchpoints). Do you think this would be doable for your compiler to remove the root requirement?

[doe300]

With integration with the VC4 kernel driver, do you mean using the /dev/vcio ioctl interface? Or do you mean writing a kernel module which calls these functions internally?

I saw the code verification you wrote into the kernel, but for now it was much easier for me to require root rights (even with its possible problems) than checking all the memory accesses. Also, currently root rights are required anyway to map the memory allocated on the VC4 to the address-space of the process (similar to what the hello_fft example program does). This could of course also be circumvented with a kernel module that handles the mapping.

[anholt]

/dev/vcio would be for talking to the closed source firmware, which shouldn't have QPU execution available when the open source vc4 driver is loaded.

if you were building on the vc4 kernel driver, then you have buffer allocation and mapping available through its interfaces.

[doe300]

[...] which shouldn't have QPU execution available when the open source vc4 driver is loaded.

Shouldn't as in the kernel code will disable it or as in it is technically possible but will cause issues?

if you were building on the vc4 kernel driver, [...]

How would I build on the vc4 kernel driver? Do I have to write a custom kernel driver which accesses its functions or is there already an existing user-space interface?

[anholt]

The branch I linked has the code for driving the engine using vc4 DRM, with a hack to redirect the old mailbox call to it. We'd need to replace the mailbox hack with a new ioctl based on the SUBMIT_CL one (see vc4_gem.c and vc4_drm.h) for SUBMIT_QPU.

[doe300]

So vc4_drv.c#L139 contains the currently available ioctls for the vc4 driver, with no ioctl yet to schedule arbitrary QPU code execution (as you already said), but some other existing ioctls I could re-use.

Am I right to assume that I access the ioctls the same way that mesa does it? E.g. that I can mmap() a BO as user with an empty base-address and simply munmap() the handle and send a DRM_IOCTL_GEM_CLOSE ioctl to release the BO again?

If we were to add an SUBMIT_QPU ioctl, then we would definitely need to verify all the memory accesses of the code execution, right? Since then the user could achieve privilege escalation.

[anholt]

Yeah, you would need to verify memory accesses to get the code into upstream Linux so it could be used generally, as we require that access to GPU command execution not escalate privilege (other than maybe reading other GPU processes' GPU buffers -- many drivers have failed at preventing that, so it's the de facto standard)

Basic buffer mapping can be seen in vc4_bufmgr.c in Mesa -- basically, you do GEM_CREATE, GEM_MMAP, then use that offset as the arg to mmap() to get the mapping of the buffer. Note that you don't get to map shaders directly, since those have to be validated by the kernel.