C3Subtitles: 35c3: Safe and Secure Drivers in High-Level Languages

Safe and Secure Drivers in High-Level Languages

How to write PCIe drivers in Rust, go, C#, Swift, Haskell, and OCaml

If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!

Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.

Video duration
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 <a href="https://github.com/ixy-languages/ixy-languages">our GitHub page</a> 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 <a href="https://github.com/ixy-languages/ixy.rs">Rust</a>, <a href="https://github.com/ixy-languages/ixy.cs">C#</a>, <a href="https://github.com/ixy-languages/ixy.go">go</a>, and <a href="https://github.com/ixy-languages/ixy.swift">Swift</a> are completely finished, tuned for performance, evaluated, and benchmarked. And all of them except for Swift are about 80-90% as fast as <a href="https://github.com/emmericp/ixy">our user space C driver</a> 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 also got something for fans of functional languages: our implementations in <a href="https://github.com/ixy-languages/ixy.ml">OCaml</a> and <a href="https://github.com/ixy-languages/ixy.hs">Haskell</a> are working but not yet tuned for performance. We are also working on Python, Java, and Javascript.
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 <a href="https://media.ccc.de/v/34c3-9159-demystifying_network_cards">last year's talk about user space driver basics</a>, 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 :)

Talk ID
12:50 p.m.
Type of
Sebastian Voit
Simon Ellmann
Paul Emmerich
Talk Slug & media link
0.0% Checking done0.0%
0.0% Syncing done0.0%
0.0% Transcribing done0.0%
100.0% Nothing done yet100.0%

English: Transcribed until

Last revision: 3 months, 3 weeks ago