Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Userland PCI drivers

wiki.netbsd.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Userland PCI drivers

#11

Post by Demeisen »

q3k wrote: post #9
djsumdog wrote: post #2

I remember seeing the PCI userspace option in the Linux kernel menuconfig and wondered why anyone would do that, and then a few years ago at Kiwicon I saw my first use case. A presenter was trying to hack a Cisco router. Older Cisco routers ran IOS directly on proprietary hardware. At some point, Cisco decided to switch to Intel hardware but didn't port their kernel. They use a Linux kernel and ran IOS as a huge 50MB…

Well, most of the magic of hardware routers also comes in the form of hardware acceleration of the actual data plane - ie. L3 switching - on the silicon itself. That's what makes them fast and so expensive. That sort of mechanism doesn't map nicely into the Linux interface paradigm (unless you do things like exporting kernel routes into the hardware, but that's borderline absurd). I think even if the driver were to b…

Isn't switchdev supposed to provide a way to make an interface to in-silicon forwarding engines?

Re: Userland PCI drivers

#13

Post by snuxoll »

q3k wrote: post #9
djsumdog wrote: post #2

I remember seeing the PCI userspace option in the Linux kernel menuconfig and wondered why anyone would do that, and then a few years ago at Kiwicon I saw my first use case. A presenter was trying to hack a Cisco router. Older Cisco routers ran IOS directly on proprietary hardware. At some point, Cisco decided to switch to Intel hardware but didn't port their kernel. They use a Linux kernel and ran IOS as a huge 50MB…

Well, most of the magic of hardware routers also comes in the form of hardware acceleration of the actual data plane - ie. L3 switching - on the silicon itself. That's what makes them fast and so expensive. That sort of mechanism doesn't map nicely into the Linux interface paradigm (unless you do things like exporting kernel routes into the hardware, but that's borderline absurd). I think even if the driver were to b…

> I think even if the driver were to be implemented in kernelspace, it would still probably not expose any of it's physical interfaces to userspace as plain ethernet devices, maybe apart from virtual/mgmt ones to run SSH on, and perhaps one so that the kernel can handle packets that the router doesn't have flows programmed for (like in OpenFlow).

That's basically how switch development works in a nutshell, look at Broadcom's OpenNSL.

Re: Userland PCI drivers

#16

Post by paulie_a »

mey wrote: post #12

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

Unless you are Cisco dev and do everything possible to screw it up

Edit: Cisco hardware was mentioned in this thread

Re: Userland PCI drivers

#17

Post by nickpsecurity »

mey wrote: post #12

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

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 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.

Re: Userland PCI drivers

#18

Post by digi_owl »

Retr0spectrum wrote: post #14

I guess monolithic kernels have gone full-circle now.

Most real life implementations of "microkernels" end up being hybrids. NT started out as a micro, but Microsoft have been moving things (the graphics subsystem in particular) in and out of kernel space in the hunt for the optimal tradeoff between stability and performance.

Similarly i think the Mach kernel powering Apple's OSs are a "fat micro" where various things that should be in userspace, if one followed the microkernel orthodoxy, resides in kernel space.

Perhaps the only orthodox microkernel OS out there is QNX, these days languishing in the bowels of Blackberry's holdings.

Re: Userland PCI drivers

#19

Post by FooBarWidget »

ajross wrote: post #5
djsumdog wrote: post #2

I remember seeing the PCI userspace option in the Linux kernel menuconfig and wondered why anyone would do that, and then a few years ago at Kiwicon I saw my first use case. A presenter was trying to hack a Cisco router. Older Cisco routers ran IOS directly on proprietary hardware. At some point, Cisco decided to switch to Intel hardware but didn't port their kernel. They use a Linux kernel and ran IOS as a huge 50MB…

For years and years, the X server was effectively a userspace device driver. It would map the configuration registers and the framebuffer and do everything outside the kernel. And it worked fine, for the most part. Once GPUs arrived, the ability to do latency-critical management of the device state became important and the register management moved into the kernel. But for traditional framebuffers the device setup wa…

From what I know, the reason they moved device setup to the kernel was to avoid flickering when the system switches from the boot screen to the login manager.

Re: Userland PCI drivers

#20

Post by convolvatron »

sfuller808 wrote: post #15
mey wrote: post #12

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

thats one advantage. another is portability.

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.
Post reply on HN