Free user space for non-graphics drivers

> I suspect the kernel <-> GPU interfaces are generally much more complex than the interfaces between the kernel and stuff in /lib/firmware, hence the reluctance.

I think it's also a question of exposure of the interface to an attacker.

On the general /lib/firmware side the issue is more potentially malicious firmware.

Unpriveleged users can't (or shouldn't) be able to change the firmware files. Most of the time the firmware won't be receiving commands directly from userspace without the kernel sanitizing them first. In fact normally the uapi will be something standard on Linux for that subsystem and the commands sent to the firmware will be completely determined by the kernel driver.

On the GPU side though it's a bit different as unpriveleged applications can submit commands to the GPU via /dev/dri (otherwise stuff like games wouldn't work). The kernel is mostly a pipe. So a malicious actor who has knowledge of a GPU exploit could submit crafted buffers to compromise the system.

The kernel can't assume that userspace is Mesa or something trusted.

But the existence of an open source userspace, even if it is bypassed by an attacker, means that the knowledge is available for the kernel to sanitize the commands. Up to a point at least because there could still exist undiscovered holes. But it's way better than an open source kernel driver accepting opaque command buffers with no idea what they do or the security implications.