The logic behind why it is done like that I get. Just wondering as You said is i...

Santosh83 · on Nov 22, 2017

I don't see how you can convert a kernel-space driver to a user-space one without significant rewriting, and in some cases it may not be possible at all.

margorczynski · on Nov 22, 2017

What about some abstraction/interfacing layer/driver that would take care of exposing some kernel functionality an average driver needs and provide additional validation?

zaarn · on Nov 22, 2017

Drivers need to do things that are inherently unsafe.

The driver responsible for you harddrive needs to instruct the SATA controller to copy a piece of data from disk to a specified memory location.

The kernel has no understanding of the process without the driver and is therefore incapable of preventing abuse.

You can somewhat prevent this using various methods but those cost performance.

And keep in mind the abstraction itself already costs performance and this doesn't even allow easy extending of the abstraction if necessary.

While microkernels that do run everything in userspace are nice in theory, you usually pay in CPU cycles compared to kernel-mode drivers.

darklajid · on Nov 22, 2017

This would be something like the Hurd for example (or Mach based systems), as far as I understand.

Over there drivers and whole subsystems are running as separate processes and just pass messages. Is that what you're interested in?

marcosdumay · on Nov 22, 2017

The "most bug-prone an exploitable" dimension is a bad one. There's probably some correlation, but it is not a good way to look at the differences.

You can push into userspace the software that work some data into some low level data. You can't push into userspace the IO of that low level data to the hardware. If your driver is mostly interpreting complex data before IO, you can push most of it into userspace, but if it is really doing IO (or calculations are interspersed with IO), you can't.