Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel [LWN.net]

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

Posted Feb 14, 2013 6:25 UTC (Thu) by brouhaha (subscriber, #1698)
In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by mjg59
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.

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

(Log in to post comments)

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.