5 ms·

Isn't the advantage of running hardware drivers in userspace to limit the attack surface of a driver being exploited?

by mey 9y ago

sfuller808 9y ago
thats one advantage. another is portability.
- convolvatron 9y ago
  there can be serious performance benefits for i/o heavy workloads: - removal of copies mandated by the user/kernel boundary - lower control transfer overhead, up to and including becoming completely polled mode. interrupt, getting into the kernel service thread from interrupt, through the kernel stack, into epoll, and into a user thread takes some time - use of device specific features without having to plumb them through all the various kernel interfaces - native asynch removing overheads associated with i/o thread pools - exploitation of workload specific optimizations that would be defeated by the kernel scheduler, memory management, buffer cache, and other machinery of course you lose all device independence from your interface, any intra-process resource sharing provided by the kernel mechanisms. you have to deal with all the error recovery and safety issues yourself. but on some occasions its really worth it.
paulie_a 9y ago
Unless you are Cisco dev and do everything possible to screw it up Edit: Cisco hardware was mentioned in this thread
nickpsecurity 9y ago
See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%20computer-2006a.pdf 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 own address space prevents errors from taking the system down. One might also use safe coding, static analysis, model-checking, etc when developing drivers themselves. Microsoft eliminated most of their blue screens with SLAM toolkit for model-checking drivers. Of the two, isolation with restarts is the easiest given you can use it on unmodified or lightly-modified drivers in many cases. Far as security, it really depends on the design of the system and hardware. The basic, isolation mechanisms like MMU's might restrict the rogue driver enough if the attack just lets them go for other memory addresses. If it uses DMA, then they might control the DMA to indirectly hit other memory or even go for peripheral firmware. If the DMA is restricted, then maybe not. It all depends as I said on what the hardware offers you plus how the system uses it. All these possibilities are why high-assurance security pushed in the 1980's-1990's to have formal specifications of every component, hardware and software, that map every interaction of state or flow of information. That didn't happen for most mainstream stuff. Without precise models, there's probably more attacks to come involving drivers interacting with underlying hardware that's complex. It's why I recommend simple, RISC CPU's with verified drivers for high-security applications. Quite a few folks from the old guard even use 8-16-bit microcontrollers with no DMA specifically to reduce these risks. Far as verifying drivers, here's a sample of approaches I've seen that weren't as heavy as something like seL4: http://spinroot.com/spin/whatispin.html http://spinroot.com/spin/whatispin.html https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf https://www.microsoft.com/en-us/research/blog/p-programming-language-asynchrony/ https://www.microsoft.com/en-us/research/blog/p-programming-... http://etd.library.vanderbilt.edu/available/etd-11172015-221551/unrestricted/YiLi.pdf http://etd.library.vanderbilt.edu/available/etd-11172015-221... https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-willem-penninckx.pdf https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-... Note: Including that last one specifically for the I/O verification part.
- my123 9y ago
  Note that Windows Vista onwards has UMDF too (user-mode driver framework). NT6.0 was a very big step.
  - repiret 9y ago
    UMDF was available for XP too, and printer drivers had been user space for a long long time.
    - my123 9y ago
      I see, was a backport there
    - blattimwind 9y ago
      iirc you can have kernel-mode GDI printer drivers, and the printer port drivers are in the kernel as well
- snvzz 9y ago
  Somewhat related, Minix3 finally fixed the release blocker for 3.4.0. Expect a release soon, for the first time in years. And it's a major one.
  - wean_irdeh 9y ago
    Where I can hear more about this one? Link please
    - snvzz 9y ago
      Wikipedia article[1] has a list of changes, based on the rc. See the column at the right. [1] https://en.wikipedia.org/wiki/MINIX_3#History https://en.wikipedia.org/wiki/MINIX_3#History
      - wean_irdeh 9y ago

Isn't the advantage of running hardware drivers in userspace to limit the attack surface of a driver being exploited?

by mey 9y ago

Isn't the advantage of running hardware drivers in userspace to limit the attack surface of a driver being exploited?

sfuller808 9y ago

thats one advantage. another is portability.

convolvatron 9y ago
there can be serious performance benefits for i/o heavy workloads: - removal of copies mandated by the user/kernel boundary - lower control transfer overhead, up to and including becoming completely polled mode. interrupt, getting into the kernel service thread from interrupt, through the kernel stack, into epoll, and into a user thread takes some time - use of device specific features without having to plumb them through all the various kernel interfaces - native asynch removing overheads associated with i/o thread pools - exploitation of workload specific optimizations that would be defeated by the kernel scheduler, memory management, buffer cache, and other machinery of course you lose all device independence from your interface, any intra-process resource sharing provided by the kernel mechanisms. you have to deal with all the error recovery and safety issues yourself. but on some occasions its really worth it.

paulie_a 9y ago

Unless you are Cisco dev and do everything possible to screw it up Edit: Cisco hardware was mentioned in this thread

nickpsecurity 9y ago

See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro: http://cs.furman.edu/~chealy/cs75/important%20papers/secure%20computer-2006a.pdf 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 own address space prevents errors from taking the system down. One might also use safe coding, static analysis, model-checking, etc when developing drivers themselves. Microsoft eliminated most of their blue screens with SLAM toolkit for model-checking drivers. Of the two, isolation with restarts is the easiest given you can use it on unmodified or lightly-modified drivers in many cases. Far as security, it really depends on the design of the system and hardware. The basic, isolation mechanisms like MMU's might restrict the rogue driver enough if the attack just lets them go for other memory addresses. If it uses DMA, then they might control the DMA to indirectly hit other memory or even go for peripheral firmware. If the DMA is restricted, then maybe not. It all depends as I said on what the hardware offers you plus how the system uses it. All these possibilities are why high-assurance security pushed in the 1980's-1990's to have formal specifications of every component, hardware and software, that map every interaction of state or flow of information. That didn't happen for most mainstream stuff. Without precise models, there's probably more attacks to come involving drivers interacting with underlying hardware that's complex. It's why I recommend simple, RISC CPU's with verified drivers for high-security applications. Quite a few folks from the old guard even use 8-16-bit microcontrollers with no DMA specifically to reduce these risks. Far as verifying drivers, here's a sample of approaches I've seen that weren't as heavy as something like seL4: http://spinroot.com/spin/whatispin.html http://spinroot.com/spin/whatispin.html https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf https://www.microsoft.com/en-us/research/blog/p-programming-language-asynchrony/ https://www.microsoft.com/en-us/research/blog/p-programming-... http://etd.library.vanderbilt.edu/available/etd-11172015-221551/unrestricted/YiLi.pdf http://etd.library.vanderbilt.edu/available/etd-11172015-221... https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-willem-penninckx.pdf https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-... Note: Including that last one specifically for the I/O verification part.

my123 9y ago
Note that Windows Vista onwards has UMDF too (user-mode driver framework). NT6.0 was a very big step.
- repiret 9y ago
  UMDF was available for XP too, and printer drivers had been user space for a long long time.
  - my123 9y ago
    I see, was a backport there
  - blattimwind 9y ago
    iirc you can have kernel-mode GDI printer drivers, and the printer port drivers are in the kernel as well
snvzz 9y ago
Somewhat related, Minix3 finally fixed the release blocker for 3.4.0. Expect a release soon, for the first time in years. And it's a major one.
- wean_irdeh 9y ago
  Where I can hear more about this one? Link please
  - snvzz 9y ago
    Wikipedia article[1] has a list of changes, based on the rc. See the column at the right. [1] https://en.wikipedia.org/wiki/MINIX_3#History https://en.wikipedia.org/wiki/MINIX_3#History
    - wean_irdeh 9y ago