More efficient?
More efficient?
Posted Jun 6, 2025 16:51 UTC (Fri) by bluca (subscriber, #118303)In reply to: More efficient? by Nahor
Parent article: Slowing the flow of core-dump-related CVEs
Posted Jun 6, 2025 17:37 UTC (Fri)
by Nahor (subscriber, #51583)
[Link] (9 responses)
The only case I can imagine where the new method would be more efficient is if one already has a crash handler daemon, and use a core_pattern helper to pass the data from the kernel to the daemon. In this case the helper can now be skipped and the core dump can go directly from the kernel to the daemon. But I doubt this is common usage, if it even exists anywhere, since it would combine the worst of both methods.
Posted Jun 6, 2025 17:54 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (6 responses)
It is, as there's one fewer process. It's already socket activated - the umh only receives the core, it doesn't do any analysis, as it's dangerous. The umh forwards the core to a different socket-activated process, that is ran at minimum privilege, which does the analysis.
> But I doubt this is common usage, if it even exists anywhere, since it would combine the worst of both methods.
It's the most common usage (whether via apport or systemd-coredump or something else), as the article writes just writing files around from the kernel is really bad, and only legacy (or manual) setups do that.
Posted Jun 6, 2025 19:25 UTC (Fri)
by Nahor (subscriber, #51583)
[Link] (5 responses)
If your crash manager already has a persistent process, like systemd does, then yes, you become more efficient. Having a persistent process for them was a sunk cost since systemd already has a persistent process for monitoring services. But the gain in efficiency for them comes from their implementation choices, from the kernel API now matching their usage better, it does not come from a more efficient API. I'm arguing the latter, you're arguing the former.
Posted Jun 6, 2025 20:49 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (4 responses)
It doesn't
Posted Jun 7, 2025 0:41 UTC (Sat)
by Nahor (subscriber, #51583)
[Link] (3 responses)
Uh? Systemd has a persistent process, it's called "systemd" daemon, aka "init", aka PID 1. What do you think monitors the various systemd units, including sockets?
Posted Jun 7, 2025 11:46 UTC (Sat)
by bluca (subscriber, #118303)
[Link] (2 responses)
It's not an _extra_ one as you implied. There's no extra cost, it's already there for other purposes.
Posted Jun 9, 2025 10:04 UTC (Mon)
by paulj (subscriber, #341)
[Link] (1 responses)
Worth it, for me I'd say yes, and I doubt anyone could notice that 1 additional feature, but you can't dismiss the argument others have on the basis there are no extra resources used.
Posted Jun 9, 2025 10:48 UTC (Mon)
by bluca (subscriber, #118303)
[Link]
With this feature it's now kernel -> socket, instead of kernel -> usermode helper -> socket.
Posted Jun 7, 2025 8:41 UTC (Sat)
by james (subscriber, #1325)
[Link] (1 responses)
Posted Jun 7, 2025 15:23 UTC (Sat)
by Nahor (subscriber, #51583)
[Link]
Probably not, but the article does assert the new API is "more efficient (since there is no need to launch new helper processes each time)". I question that (at least a generalization, since it's true for the particular case of systemd, because systemd-coredump's main part is already socket-based, so now it can just drop the core_pattern helper part).
More efficient?
More efficient?
Now we can remove the middleman.
More efficient?
More efficient?
More efficient?
>
> It doesn't
More efficient?
More efficient?
More efficient?
More efficient?
but it then needs to start a new process to handle a crash, like core_pattern did, so it's no more efficient than before.
Is this really the sort of efficiency we should be optimising for? I mean, by definition we've just had a program crash: this should not be a common occurrence!
More efficient?