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:
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
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.
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
https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf
https://www.microsoft.com/en-us/research/blog/p-programming-...
http://etd.library.vanderbilt.edu/available/etd-11172015-221...
https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-...
Note: Including that last one specifically for the I/O verification part.