Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 14, 2013 6:09 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by brouhaha
Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

GPUs can do DMA. Allowing userspace to submit arbitrary commands to GPUs means that userspace can do arbitrary DMA, and as such means that any application with access to your GPU can do anything it wants to. As such, you need command validation in the kernel in order to prevent userspace from being able to cross security boundaries. The kernel needs DRM support to validate the commands that userspace submits.

Modesetting. The kernel needs to be able to reprogram a mode over suspend/resume. That means that the kernel needs to be able to program the mode that userspace requested. You need modesetting support in kernel. At that point, allowing userspace to program a mode that doesn't match the kernel's expectations is dangerous. The kernel needs to be able to set modes.

There's plenty that the kernel does that can't be handled in userspace, simply because (a) we don't trust userspace, and (b) userspace doesn't run during suspend/resume. You could write an operating system that did all of that in userspace, but it'd be shit and incapable of meeting modern expectations of OS security. The only reason to push hardware management out of your kernel is because you're producing a microkernel, and Linux isn't.

Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 14, 2013 6:25 UTC (Thu) by brouhaha (subscriber, #1698) [Link] (2 responses)

GPUs can do DMA. Allowing userspace to submit arbitrary commands to GPUs means that userspace can do arbitrary DMA, and as such means that any application with access to your GPU can do anything it wants to.

Which is why you wouldn't let just any userspace application access the GPU directly. I don't let just any userspace application scribble on /dev/sda either.

I'll accept your argument for modesetting for suspend/resume.

There's plenty that the kernel does that can't be handled in userspace, simply because (a) we don't trust userspace,

That's a bizarre argument. Having code in user space doesn't magically make it less trustworthy than the same code would be in kernel space. Whether particular code should be trusted is a matter of policy, and there are various mechanism for policy enforcement.

The only reason to push hardware management out of your kernel is because you're producing a microkernel,

Assumes facts not in evidence. At the very large router company, we pushed hardware management out of the kernel for many reasons, none of which had anything whatsoever to do with whether the kernel we were running was monolithic or a microkernel. I could certainly accept that *A* reason to push hardware management out of your kernel is because you're producing a microkernel. It's a big jump from *A* to *The only*.

Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 14, 2013 6:33 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

"Which is why you wouldn't let just any userspace application access the GPU directly."

Yes! You shouldn't let any userspace application access the GPU directly, because these days we have an expectation that userspace shouldn't be able to compromise the kernel. The alternative is to have signed userspace, and that's not an acceptable option. So, unless you're producing a microkernel which has a separation between drivers and the rest of userspace (which Linux doesn't have), the correct line to draw is the one where only the kernel gets to drive hardware that can overwrite the rest of the OS.

Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel

Posted Feb 14, 2013 17:27 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> That's a bizarre argument. Having code in user space doesn't magically make it less trustworthy than the same code would be in kernel space. Whether particular code should be trusted is a matter of policy, and there are various mechanism for policy enforcement.

Sure it does, the kernel has no control over what is run in user space and can make no assumptions about it being the "same code" or some expected implementation, it can have zero trust that the data given to it from userspace isn't bogus and absolutely must check everything. This is different than a closed environment like an appliance where one entity has control of both userspace and kernelspace, maybe restrictions could be relaxed in that case.