Free user space for non-graphics drivers [LWN.net]

Free user space for non-graphics drivers

Posted Jun 3, 2020 22:08 UTC (Wed) by blackwood (guest, #44174)
In reply to: Free user space for non-graphics drivers by roc
Parent article: Free user space for non-graphics drivers

Well this is why drivers/gpu requires fully open stack in the userspace side of things. Allows us to review the entire thing, figure out whether the security model has a reasonable chance of working. Backstop it with kernel-side validation if necessary, which has huge uapi impact since you can't validate Turing complete stuff, so you need to figure out a way to limit the Turing completeness to where it doesn't matter for security, without impacting the functionality exposed to userspace in a way that users care about.

Plus when (this isn't an if in a post smeltdown world) the hw security features turn out to be more leaky than presumed, we have a fighting chance to fix up the mess going forward.

But without all that it's indeed hopeless, and you might as well assume your kernel is compromised.

to post comments

Free user space for non-graphics drivers

Posted Jun 4, 2020 15:48 UTC (Thu) by nivedita76 (subscriber, #121790) [Link] (1 responses)

I'm not really close to this stuff, but I don't see how even getting open-source userspace is really enough for security. That tells you if the vendor-provided user-space library can be compromised, but you really need to get specifications for what the hardware is capable of doing, not just what the vendor-provided userspace uses it for, since a real attacker could do something completely different with the provided ioctl's.

Free user space for non-graphics drivers

Posted Jun 4, 2020 21:26 UTC (Thu) by blackwood (guest, #44174) [Link]

Even the hw spec doesn't give you security, the hw might not live up to it, see smeltdown.

What an open stack allows you is to fix up the mess once you are aware of a security hole. Worst case you might end up with something like CONFIG_ENABLE_ROOTHOLES to not break existing uapi if the old one is unfixable. But going forward you can change both kernel and userspace driver parts to come up with something to work around the security holes. But often the breakage is really minor (like more gpu hangs in some corner case), so good enough if you just ship bugfixes on both sides. If one part is an opaque blob you can't really reason about, much less change, then that's all impossible. And vendors abandon their closed source stacks real fast, better if they sell you new hw with new drivers.