Linux

🧭 Where we left off Welcome back to our technical journey on measuring binary test coverage! In part 4 we introduced funkoverage, a native, high-performance eBPF-based coverage tracer that leverages uprobe_multi to capture function entry events in GNU/Linux with less than 2% overhead. It parses static library dependencies using ldd during installation and maps uprobes to all discovered functions. But there was a big fat elephant in the room: dlopen(). Some of the most complex, modular software in the world — such as web servers with dynamic modules, plugin-based enterprise applications, and multi-protocol databases — load their dependencies at runtime on-the-fly. Because these libraries are not declared in the ELF binary’s DT_NEEDED header, they are invisible to ldd during installation. Today, we are going to chase the dynamic loading ghost, explore how we solved this with an elegant, highly scalable, event-driven eBPF JIT instrumentation strategy, and battle-test it live on standard, unmodified production binaries like Nginx and OpenSSL! ...

🤔 What’s a syscall, anyway? Image credits: Mike Norris via Pexels Every time your program reads a file, writes to a socket, or allocates memory, at some point it has to ask the kernel to actually do it. That ask is a syscall, the narrow, well defined boundary where userspace code crosses into the kernel. write(), read(), open(), mmap(), these aren’t just library functions, they’re the entire vocabulary your program has for talking to the outside world. Everything else, fwrite, Python’s file.write(), std::fs::File, is just a wrapper around this same handful of kernel entry points. ...

🧭 Where we left off Welcome back to our ongoing series on measuring test coverage for binary programs! In part 1 we used Go’s built-in -cover flag — clean and accurate, but only works if you own the source and can recompile. In part 2 we used valgrind and gdb to trace gzip without touching its source. In part 3 we explored Intel PIN, a proper dynamic binary instrumentation framework — powerful, but it came with a ~100MB proprietary C++ SDK and was limited to x86_64. ...

📦 That new package smell We’ve all been there: you see a shiny new app on GitHub and you want to “unwrap” it immediately. But in the traditional Linux world, opening a package often feels like opening a box of glitter in your living room—before you know it, dependencies are scattered everywhere, and you’re still finding weird library versions in /usr/lib three months later. This is why I’ve started reaching for the Flatpak. It’s like an unboxing experience where the box stays a box. You get all the “goodies” inside, but the mess stays contained. Let’s see what happens when we tear off the shrink-wrap. ...