5 ms·

Quick question - doesn't Linux driver model (they run in kernel-space) create a giant attack vector because of that?

TheChaplain 9y ago
AFAIK you must be root to load kernel modules.
mschuster91 9y ago
Lots of drivers on Windows, OS X and Linux run in kernel space simply because kernel-to-user-and-back context switches are expensive and so kill performance. I believe the exceptions are printer and scanner drivers (these run in user-space CUPS in OS X/Linux), some filesystem drivers (basically, FUSE-backed) and cheap-ish USB drivers.
- margorczynski 9y ago
  The logic behind why it is done like that I get. Just wondering as You said is it possible to push at least the most bug-prone and exploitable ones to user-space
  - darklajid 9y ago
    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?
  - Santosh83 9y ago
    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 9y ago
      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 9y ago
        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.
  - marcosdumay 9y ago
    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.
- AnIdiotOnTheNet 9y ago
  Since WDDM, a good portion of the display driver in Windows is in user space, as are sound and network drivers. This is how you can upgrade your graphics driver without rebooting or even losing your open windows, and why network and sound driver crashes don't usually bluescreen. It is probably the biggest reason why Windows doesn't crash anywhere near as often as it used to.
- ThenAsNow 9y ago
  But there are ways to reduce the attack surface with minimal impact to performance, e.g. the Microdrivers approach: https://www.cs.rutgers.edu/~vinodg/papers/asplos2008/asplos2008.pdf https://www.cs.rutgers.edu/~vinodg/papers/asplos2008/asplos2...
debatem1 9y ago
Yes. Poorly written drivers are a major piece of attack surface for Linux devices.

AFAIK you must be root to load kernel modules.

Lots of drivers on Windows, OS X and Linux run in kernel space simply because kernel-to-user-and-back context switches are expensive and so kill performance. I believe the exceptions are printer and scanner drivers (these run in user-space CUPS in OS X/Linux), some filesystem drivers (basically, FUSE-backed) and cheap-ish USB drivers.

margorczynski 9y ago
The logic behind why it is done like that I get. Just wondering as You said is it possible to push at least the most bug-prone and exploitable ones to user-space
- darklajid 9y ago
  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?
- Santosh83 9y ago
  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 9y ago
    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 9y ago
      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.
- marcosdumay 9y ago
  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.
AnIdiotOnTheNet 9y ago
Since WDDM, a good portion of the display driver in Windows is in user space, as are sound and network drivers. This is how you can upgrade your graphics driver without rebooting or even losing your open windows, and why network and sound driver crashes don't usually bluescreen. It is probably the biggest reason why Windows doesn't crash anywhere near as often as it used to.
ThenAsNow 9y ago
But there are ways to reduce the attack surface with minimal impact to performance, e.g. the Microdrivers approach: https://www.cs.rutgers.edu/~vinodg/papers/asplos2008/asplos2008.pdf https://www.cs.rutgers.edu/~vinodg/papers/asplos2008/asplos2...

debatem1 9y ago

Yes. Poorly written drivers are a major piece of attack surface for Linux devices.