Userland PCI drivers • Hacker News Board

Re: Userland PCI drivers

#51

Post by wean_irdeh » Tue, Mar 27, 2018, 9:55 AM UTC

tinus_hn wrote: post #49

nickpsecurity wrote: post #17

Earlier quoted context omitted.

See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%... The main benefit is reliability. Driver code is usually lower-quality than other code that runs in kernels. The hardware itself can act weird in a way that messed the drivers up. The infamous Blue Screen of Death on Windows was usually driver errors. Isolating them in their…

It’s nice if drivers are not running in the kernel but even if your graphics drivers are running in userspace, if they crash you can’t use your pc anymore. The main advantage is that you don’t have to deal with all the limitations of kernel mode programming.

You forget that if the graphic drivers crash in the userspace, it can be automatically restarted, while if it crash in kernel space, nothing you can do except hard reboot

Re: Userland PCI drivers

#52

Post by wean_irdeh » Tue, Mar 27, 2018, 9:57 AM UTC

tinus_hn wrote: post #50

snvzz wrote: post #8

Liedtke was right. If it can be done outside the kernel, it shouldn't be in the kernel.

That’s a great idea if you don’t care about performance.

Being in userspace doesn't mean compromised performance, just like how QNX has done for decades

Re: Userland PCI drivers

#53

Post by nickpsecurity » Tue, Mar 27, 2018, 2:57 PM UTC

tinus_hn wrote: post #49

nickpsecurity wrote: post #17

Earlier quoted context omitted.

See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%... The main benefit is reliability. Driver code is usually lower-quality than other code that runs in kernels. The hardware itself can act weird in a way that messed the drivers up. The infamous Blue Screen of Death on Windows was usually driver errors. Isolating them in their…

It’s nice if drivers are not running in the kernel but even if your graphics drivers are running in userspace, if they crash you can’t use your pc anymore. The main advantage is that you don’t have to deal with all the limitations of kernel mode programming.

On top of wean_irdeh's comment, Ill add you might have apps running in the background that can still do work (esp networked) or just shut down cleanly. There can even be a keyboard sequence for that.

Re: Userland PCI drivers

#54

Post by snvzz » Tue, Mar 27, 2018, 7:02 PM UTC

tinus_hn wrote: post #50

snvzz wrote: post #8

Liedtke was right. If it can be done outside the kernel, it shouldn't be in the kernel.

That’s a great idea if you don’t care about performance.

Common misconception. I suggest this article.

https://blog.darknedgy.net/technology/2016/01/01/0/

Re: Userland PCI drivers

#55

Post by kijiki » Thu, Mar 29, 2018, 12:20 AM UTC

tinus_hn wrote: post #48

kijiki wrote: post #30

Earlier quoted context omitted.

There were a bunch of reasons. One important one is that accessing the PCI config space via IO ports 0xCF8/0xCFC is racy with the kernel, since a read or write requires writing the BDF address to 0xCF8, and then reading/writing the data from 0xCFC. If the kernel tries to do this dance while the X server is doing it as well one of them is going to read or write the wrong address. Interestingly, this design required in…

Csrss.exe is the userspace part of the win32 personality. It controls all win32 processes, which on a Windows system is just about every process. It is not very useful to limit its privileges.

After the graphics driver moved out of it and into the kernel, it probably no longer needs the ability to turn off interrupts and read and write legacy IO ports.