Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

integration with vc4 DRM driver #51

Open
anholt opened this issue Jan 22, 2019 · 6 comments
Open

integration with vc4 DRM driver #51

anholt opened this issue Jan 22, 2019 · 6 comments

Comments

@anholt
Copy link

anholt commented Jan 22, 2019

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
Copy link
Owner

doe300 commented Jan 22, 2019

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
Copy link
Author

anholt commented Jan 23, 2019

/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
Copy link
Owner

doe300 commented Jan 27, 2019

[...] 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
Copy link
Author

anholt commented Jan 28, 2019

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
Copy link
Owner

doe300 commented Jan 29, 2019

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
Copy link
Author

anholt commented Mar 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants