Safe and Secure Drivers in High-Level Languages - Paul Emmerich, Simon Ellmann, Sebastian Voit
35c3 - Resilience - 12/29/2018
Drivers are usually written in C for historical reasons, this can be bad if you want your driver to be safe and secure. We show that it is possible to write low-level drivers for PCIe devices in modern high-level languages.
We are working on super-fast user space network drivers for the Intel 82599ES (ixgbe) 10 Gbit/s NICs in different high-level languages. We've got fully working implementations in Rust, C#, go, OCaml, Haskell, and Swift. All of them are written from scratch and require no kernel code.
Check out our GitHub page with links to all implementations, performance measurements, and publications for further reading.
Supposedly modern user space drivers (e.g., DPDK or SPDK) are still being written in C in 2018 :(
This comes with all the well-known drawbacks of writing things in C that might be prevented by using safer programming languages.
Also, did you ever see a kernel panic because a driver did something stupid? It doesn't have to be that way, drivers should not be able to take down the whole system.
There are three steps to building better drivers:
1. Write them in a safer programming language eliminating whole classes of bugs and security problems like bad memory accesses
2. Isolating them from the rest of the operating system: user space drivers that drop privileges
3. Isolating the hardware using the IOMMU
We show that it is possible to achieve all of these goals for PCIe drivers on Linux by implementing user space network drivers in all of the aforementioned programming languages. Our techniques are transferable to other drivers that would benefit from more modern implementations.
Our drivers in Rust, C#, go, and Swift are completely finished, tuned for performance, evaluated, and benchmarked. And all of them except for Swift are about 80-90% as fast as our user space C driver and 6-10 times faster than the kernel C driver. We also investigate how garbage collectod languages affects the latency of a packet forwarder built on top of our drivers.
We take a brief look at Haskell, Swift, OCaml, and C# in the talk and a deeper dive into Rust and Go.
The talk also features a quick summary from last year's talk about user space driver basics, so no previous knowledge is required.
Another thing to take away from this talk is: writing drivers is neither scary nor hard. You can write one in your favorite programming language, so go ahead and try that :)