A crash dump looks like evidence. To a debugger, it is also input: a dense mix of memory, symbols, types, addresses, and metadata that must be parsed before the evidence becomes useful. That distinction is the center of drgn 0.3, highlighted by Phoronix after its October 9 release.
drgn is a programmable debugger developed at Meta for Linux kernel work. Instead of making an operator learn a large command language, it exposes program types and variables to Python. The same interface can inspect a running kernel, attach to a userspace C process, or open a kernel or userspace core dump. It is both an interactive debugger and a library for building purpose-specific inspection tools.
The headline in 0.3 is not a new command. It is a threat model. The project now states that ELF and DWARF debugging information is untrusted, the target being inspected is untrusted, and Python code chosen by the user is trusted. The release hardens the boundary between those three worlds.
Diagnostic evidence does not become safe just because the system that produced it has already stopped running.
A Debugger Is A Parser With Privileges
Debuggers sit in an awkward security position. They consume some of the most structurally complicated files in systems work, then run in environments where operators may grant them broad access. Kernel analysis often involves root privileges, symbols from separate packages, and dumps copied from machines that failed in ways nobody yet understands.
ELF and DWARF are not inert labels attached to a binary. They describe sections, offsets, types, ranges, expressions, line tables, and relationships among structures. A core dump adds another map of memory and machine state. Any parser walking those structures has to survive absurd sizes, cycles, impossible offsets, truncated records, and combinations that a normal compiler would never emit.
That is why drgn 0.3's hardening work matters beyond drgn. The upstream notes list fixes for buffer overflows, out-of-bounds reads, null dereferences, use-after-free errors, double frees, and uninitialized reads. They also call out integer overflow, invalid arithmetic, unbounded recursion through cyclic or deeply nested data, missing error checks, and memory leaks.
This is not a claim that every dump is an exploit. It is a recognition that a debugger cannot assume a dump is well formed. A corrupted machine can produce corrupted state accidentally. An incident responder may also receive an artifact from a machine that was controlled by somebody else. Robustness and security meet at the same parser boundary.
The Threat Model Is The Feature
Security improvements are often reported as a count of fixed bugs. drgn's more useful move is to name what it trusts. Debug information is untrusted. The target is untrusted. User-supplied Python is trusted, although the project still tries to catch misuse.
Input Trust decision
ELF / DWARF debug information untrusted
Core dump or live target untrusted
Python selected by the operator trusted
That separation prevents a common category error. A programmable debugger deliberately executes code, but that does not mean every byte it reads should inherit the operator's trust. The script is an instruction. The dump is data. Treating both as equally trusted would turn opening evidence into an implicit decision to run with the evidence's assumptions.
The model is also honest about limits. Python can call native extensions, allocate enormous objects, or direct the debugger toward nonsensical addresses. Protecting an operator from every script they intentionally execute is a different problem from ensuring that a malformed type graph cannot walk the C parser off the edge of memory.
Programmability Changes The Debugging Loop
drgn's appeal is that debugging can look like ordinary analysis code. A kernel task is an object with fields. A linked list can be traversed by a helper. A stack trace can be stored, filtered, and combined with application-specific checks. The operator does not have to repeatedly translate a question into a debugger command, copy the answer somewhere else, and start again.
$ drgn -c /evidence/vmcore
>>> task = find_task(4152)
>>> trace = stack_trace(task)
>>> [frame.name for frame in trace]
That matters when a failure is distributed across interconnected structures. A scheduler question may require following tasks into run queues, checking CPU state, grouping results, and testing an invariant across thousands of objects. A general-purpose language gives the investigation loops, collections, tests, reusable functions, and normal source control.
It also makes repeatability possible. An incident team can preserve the original dump, pin the debugger version, record the symbol set, and run the same analysis script against multiple machines. The output becomes an artifact of a defined procedure instead of a transcript of one operator's terminal.
QEMU Speed Comes From A Narrower Path
drgn 0.2 added QEMU guest debugging through the QEMU Machine Protocol. It worked, but reading guest memory through QMP was slow. Version 0.3 can find the QEMU process and read guest memory directly instead.
The optimization is conditional. The QMP connection must use a Unix domain socket, and drgn must have Linux ptrace permission to read the QEMU process memory. Those requirements are not incidental plumbing. They define the local identity and authorization assumptions that make the faster path acceptable.
This is a good systems pattern: keep the portable control channel, then use a local data path when the environment can prove enough about proximity and access. It avoids turning faster debugging into a broad remote-memory interface. Operators still need to treat ptrace access as sensitive, because permission to inspect QEMU memory is permission to inspect the guest's memory.
Kernel Internals Keep Moving
The release also repairs helpers affected by Linux 7.2 and 7.3. A kernel change broke the crash-compatible irq command because the expected nr_irqs lookup no longer worked. drgn 0.3 adds irq_get_nr_irqs() to retrieve the count across kernel versions.
Linux 7.3 changes affected path lookup, scheduler run-queue iteration, and the fsrefs.py tool's handling of binfmt_misc. None of these are glamorous failures. They are exactly the sort that make low-level observability tooling expensive to maintain: the tool's job is to interpret internal structures whose shape and meaning can change underneath it.
A debugger that opens yesterday's dump but silently skips part of today's kernel is dangerous in a different way from one that crashes. It can return a plausible incomplete answer. Compatibility work therefore belongs beside parser hardening. Both are about refusing to turn unknown structure into false confidence.
Operate Dumps Like Forensic Inputs
drgn 0.3 improves the parser, but teams still own the environment around it. A useful operating model is closer to handling an untrusted archive than opening a log file.
- Preserve the original dump and debugging files, record cryptographic hashes, and analyze working copies.
- Keep drgn and its native dependencies current; parser hardening only helps after it reaches the analysis host.
- Prefer offline analysis for untrusted dumps so the debugger does not also need access to a production kernel.
- Run with the least privilege the target requires. Do not make root the default merely because some live-kernel workflows need it.
- Separate symbol provenance from dump provenance. A trusted symbol package does not make an untrusted dump safe, and the reverse is also true.
- Pin analysis scripts and review imported Python modules. The project's model treats that code as trusted.
- Use a disposable, network-restricted analysis environment when evidence comes from an unknown or compromised system.
- Record debugger, kernel, architecture, and symbol versions with the findings so somebody else can reproduce the path.
Isolation is not a substitute for a safe parser, and a safe parser is not a substitute for isolation. The two controls cover different failures. The parser should reject malformed structures without memory corruption. The environment should limit the consequences when the parser, a dependency, or an analysis script still behaves unexpectedly.
Evidence Is Still Input
drgn 0.3 is a useful release because it improves the tool and clarifies the mental model around it. Programmability makes deep systems questions easier to express. Hardening makes it less risky to ask those questions of damaged or adversarial state. Faster QEMU reads make a virtual machine investigation less tedious without erasing the permission boundary.
The larger lesson is simple: observability tools are part of the attack surface. Logs, traces, packets, symbols, minidumps, and core files all cross a boundary from the observed system into the software that explains it. The more privileged and complex the explanation tool is, the more explicit that boundary should be.
A dump can tell the truth about a failure and still be hostile to the program reading it. drgn 0.3 treats both facts as real.
// Discussion
Comments
No comments yet. Start the thread.