drgn Writing to Memory and Breakpoints, Safely in Production?
summary
drgn is read-only today and the concrete proposal is to add write arbitrary addresses and file:line breakpoints so scripts can patch running kernels to mitigate bugs (example: a Meta btrfs bug where a missing discard-enable bit could have been flipped by a drgn script). API ideas: byte-buffer writes, object-aware writes, breakpoints by addr/function/file:line returning stack and locals. Mechanisms considered: resurrect devkm (no), kernel module, kgdb stops all CPUs, kprobes, BPF; problems: lockdown, capability/auth (keyring), deadlock — propose watchdog bailout.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 1:06What is drgn?
- 6:04Read-only vs write features
- 7:09Memory writing API proposal
- 8:33Breakpoints API proposal
- 12:48Why do this in production?
- 16:24Mechanisms for production
- 23:53Access control and security
- 27:45Alternative approaches
- 28:27Wrap-up and Q&A
related talks
38mKernel Hardening: Protecting the Protection Mechanisms
59mCool stuff about GDB you didn't know
34mGetting on the Same (Virtual Memory) Page: A Roundtable on Data-only Attack Mitigations
30mKernel Hardening With Protection Keys
29mThwarting Unknown Bugs: Hardening Features in the Mainline Linux Kernel
01h 03mret2dir: Deconstructing Kernel Isolation
43mDebug for Bug: Crack and Hack Apple Core by Itself
17mDebuggers from scratch