Conversation
Christian Brauner 🦊🐺
brauner@mastodon.social
Edited 25 days ago
I'm thinking about adding a mode where the kernel doesn't actually write out a coredump but instead just uses the socket we'll add as a synchronization mechanism (see an earlier discussion with @jann). The userpace coredump server would use SO_PEERPIDFD to get a pidfd for the crashing process and the kernel would wait for it to tell it to finish (closing the socket).
Userpace would then be able to generate its own coredump based on /proc/<PID>. I wonder if @osandov could use this for drgn.
2
0
0
Christian Brauner 🦊🐺
brauner@mastodon.social
@osandov (As a side-effect this would e.g., allow to solve a problem where the kernel currently sends potentially massive amounts of zeroed data to the coredump server (a big executable that as allocated a lot of zeroed memory).)
0
0
0
Omar Sandoval
osandov
@brauner nice! I think it'd be pretty cool to set the coredump handler to a drgn script that could directly extract only the desired information without needing to capture a full core dump at all. I think I saw this scroll by in your discussion with @jann, but I assume /proc/pid/mem, /proc/pid/maps, etc. are still alive at that point? In particular, drgn would love to use /proc/pid/map_files/ so that it unambiguously gets the correct files, but that requires PTRACE_MODE_READ_FSCREDS, so it couldn't be fully unprivileged
1
0
0
0
0
0