BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.all-systems-go.io//all-systems-go-2025//3ETHEU
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-all-systems-go-2025-MADB7R@cfp.all-systems-go.io
DTSTART;TZID=CET:20251001T112500
DTEND;TZID=CET:20251001T120500
DESCRIPTION:Coredumping on Linux has long been a nightmare. Currently two m
 odes are supported:\n\n(1) Dumping directly into a file somewhere on the f
 ilesystem.\n(2) Dumping into a pipe connected to a usermode helper process
  spawned as a child of the system_unbound_wq or kthreadd.\n\nFor simplicit
 y I'm mostly ignoring (1). There's probably still some users of (1) out th
 ere but processing coredumps in this way can be considered adventurous esp
 ecially in the face of set*id binaries.\n\nThe most common option should b
 e (2) by now. It works by allowing userspace to put a string into /proc/sy
 s/kernel/core_pattern like:\n\n        |/usr/lib/systemd/systemd-coredump 
 %P %u %g %s %t %c %h\n\nThe "|" at the beginning indicates to the kernel t
 hat a pipe must be used. The path following the pipe indicator is a path t
 o a binary that will be spawned as a usermode helper process. Any addition
 al parameters pass information about the task that is generating the cored
 ump to the binary that processes the coredump.\n\nIn the example core_patt
 ern shown above systemd-coredump is spawned as a usermode helper. There's 
 various conceptual consequences of this (non-exhaustive list):\n\n- system
 d-coredump is spawned with file descriptor number 0 (stdin) connected to t
 he read-end of the pipe. All other file descriptors are closed. That speci
 fically includes 1 (stdout) and 2 (stderr). This has already caused bugs b
 ecause userspace assumed that this cannot happen (Whether or not this is a
  sane assumption is irrelevant.).\n\n- systemd-coredump will be spawned as
  a child of system_unbound_wq. So it is not a child of any userspace proce
 ss and specifically not a child of PID 1. It cannot be waited upon and is 
 in a weird hybrid upcall which are difficult for userspace to control corr
 ectly.\n\n- systemd-coredump is spawned with full kernel privileges. This 
 necessitates all kinds of weird privilege dropping excercises in userspace
  to make this safe.\n\n- A new usermode helper has to be spawned for each 
 crashing process.\n\nOn recent kernels a new mode has been added making us
 e of AF_UNIX sockets. This talk will talk about the new modes\, how they c
 an be used\, what advantages they have in comparison to the other modes\, 
 and look at technical implementation details.
DTSTAMP:20260315T023127Z
LOCATION:Loft
SUMMARY:New Linux Kernel Coredump Infrastructure - Christian Brauner
URL:https://cfp.all-systems-go.io/all-systems-go-2025/talk/MADB7R/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-all-systems-go-2025-3BMJVH@cfp.all-systems-go.io
DTSTART;TZID=CET:20251001T140500
DTEND;TZID=CET:20251001T144500
DESCRIPTION:File descriptors for processes on Linux have been available for
  quite some time now. Userspace has adapted them widely.\n\nOver the last 
 two years or so we've extended the abilities of pidfds significantly. This
  talk will go over all the new features and deep dive into their implement
 ation and usage.
DTSTAMP:20260315T023127Z
LOCATION:Loft
SUMMARY:pidfd: What have we been up to? - Christian Brauner
URL:https://cfp.all-systems-go.io/all-systems-go-2025/talk/3BMJVH/
END:VEVENT
END:VCALENDAR