Free user space for non-graphics drivers

Posted Jun 7, 2020 22:11 UTC (Sun) by mfuzzey (subscriber, #57966)
In reply to: Free user space for non-graphics drivers by marcH
Parent article: Free user space for non-graphics drivers

>I'm not sure how that compares from a security perspective to loading a dozen /lib/firmwares

That depends what is done with the stuff loaded from lib/firmware.

Normally it will be loaded onto some other device so the risk depends on the level of hardware access that device has to memory and the degree to which Linux can restrict it (by an IOMMU for example).

So for example firmware loaded into an I2C connected touchscreen controller is unlikely to be able to do much harm since that bus provides no DMA capacity, worst case it could simulate clicks to enter false data (assuming it knows what is on the screen).

On the other hand firmare for hardware with bus mastering DMA capabilities not restricted by an IOMMU basically has full system access.

Free user space for non-graphics drivers

Posted Jun 8, 2020 19:05 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> Normally it will be loaded onto some other device so the risk depends on the level of hardware access that device has to memory and the degree to which Linux can restrict it (by an IOMMU for example).

IOMMU is apparently hit-and-miss: https://lwn.net/Articles/782381/

> On the other hand firmare for hardware with bus mastering DMA capabilities not restricted by an IOMMU basically has full system access.

Thanks, so let's stop pretending the kernel cares about attack vectors from co-processors when it doesn't even log the filenames loaded from /lib/firmware/ by default [*]

These attack vectors and pseudo-security concerns being out of the picture, that leaves only the maintenance (troubleshooting and refactoring) questions. 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. Is
that higher GPU complexity why there is a "line in the sand" somewhere in the middle, do I get that right? Or because /lib/firmware has been causing fewer maintenance headaches in the past? Or both.

[*] As the distributed system bootloader that it is, in an ideal world request_firmware() should check signatures. I digress.

Free user space for non-graphics drivers

Posted Jun 8, 2020 19:43 UTC (Mon) by mfuzzey (subscriber, #57966) [Link]

> 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.