June 21, 2026
Call me maybe, kernel
System call instrumentation on Linux/x86‑64 using memory‑indirect calls, part I
Linux syscall hack sparks a nerd civil war over speed, safety, and pure bloat
TLDR: The post explores a clever way to monitor Linux system requests with less slowdown, but the comments instantly turned it into a fight about whether Linux’s design is smart engineering or a self-inflicted mess. One side says the system model is fundamentally flawed; the other says the whole effort is overblown nerd bloat.
A deeply nerdy post about making Linux programs watch and reroute system calls somehow turned into a delicious comment-section showdown over whether Linux’s whole design is genius or a decades-old mistake. The author is trying to avoid a clunky two-step trap that slows everything down, exploring a sneaky trick that swaps a tiny "ask the kernel" instruction for another tiny instruction that can redirect execution instead. In plain English: it’s about making low-level program monitoring less awkward, less slow, and a lot less painful.
But the real fireworks came from the peanut gallery. One camp basically yelled that Linux brought this on itself by letting any program talk to the kernel directly in a stable, long-lasting way. User quotemstr called that model a "terrible idea", arguing that if programs were forced through a standard library first, the system could intercept requests more cleanly before they hit the operating system. That’s the architectural purist take: Linux made life harder, and now everyone is inventing elaborate workarounds.
Then came the drive-by flamethrower. User freestanding dismissed the whole thing as "graphomania" and grumbled that system calls are easy, this is needless bloat, and yes, even dragged the license into it with a snarky "lefty GNUnix license" jab. So the vibe was half research seminar, half food fight: some readers admired the cleverness, others saw overengineering, and everyone seemed one sarcastic aside away from posting the popcorn emoji.
Key Points
- •The article says libsystrap currently instruments Linux x86-64 system calls by replacing them with `ud2`, which causes a `SIGILL` trap and then executes the real syscall inside the signal handler, creating double-trap overhead.
- •It reviews prior work including Liteinst, E9Patch, zpoline, lazypoline, and K23 as research relevant to instruction punning and syscall instrumentation.
- •A core technical obstacle is that Intel jump instructions are typically at least 5 bytes long, while a syscall instruction is effectively 2 bytes long, making direct patch replacement difficult.
- •The post explains instruction punning as using bytes from following instructions to form a relative jump displacement, but notes that little-endian encoding leaves limited control over the target and often requires fallback strategies.
- •It presents zpoline as a cleaner method that rewrites `syscall` to `call *%rax`, but notes that this requires executable mappings near address zero and therefore weakens normal null-pointer protections unless mitigated.