Systems Software | OS Internals, Drivers & the Network Datapath
I work on software close to the hardware: how drivers behave when devices misbehave, how packets move from the NIC to a socket, and where latency actually goes. I care about correctness under failure, and I'd rather measure a system than guess about it.
- π§ Now: building Hostile Device β a harness that plays a failing emulated PCIe device against real, unmodified Linux drivers under load, and judges whether they recover
- π§ Lab: a debug mainline kernel in QEMU with gdb attached (KASAN, lockdep, kmemleak) β kernel modules and drivers get written and broken there, never on the host
- π Learning in public: C++ from the ground up (RAII, move semantics, memory ordering, cache-aware layout), C in its kernel dialect, computer architecture, and the Linux networking stack
- π± Open source: Apache Pulsar contributor; currently reading rdma-core ahead of contributing
- βοΈ Philosophy: every design gets a deliberately injected failure before I trust it
| Project | What it is | Stack |
|---|---|---|
| Hostile Device (in progress) | Fault injection at the PCIe boundary: event-triggered faults (withheld interrupts, all-1's reads after surprise removal, bogus completions) in QEMU device models, run against upstream drivers carrying real traffic. Every finding replays deterministically | C, QEMU, Linux kernel |
| Rewind | Local-first snapshot system β content-defined chunking, Zstandard reverse deltas, SQLite manifests. Two research papers on it | Go, SQLite |
| Styx | VPN built from scratch β control plane and packet engine split across a Unix domain socket, ChaCha20-Poly1305 | Rust, Java |
- Apache Pulsar β Redis sink connector: ACL support + TLS hardening (#126), TLS peer verification and truststore support (#135)
