Den 2021-11-23 kl. 23:41, skrev ebiederm@xmission.com:
Thomas Backlund tmb@iki.fi writes:
Den 2021-11-23 kl. 21:24, skrev ebiederm@xmission.com:
Maybe I am wrong but I think "Don't always set SA_IMMUTABLE for forced signals" will apply if you drop the hunk modifying force_fatal_sig. Then you don't need to backport all of the cleanups just the fix.
I will take a quick look and verify that.
that's why i wrote: "if the other patch for signal that has similar description should land"
Apologies for not responding to that bit, I was reading quickly and I missed that bit.
No worries :)
The second patch does not need to land in 5.15.
(meaning "signal: Replace force_fatal_sig with force_exit_sig when in doubt")
as thats the one needing the whole patch series...
since going by patch descriptions for:
"signal: Don't always set SA_IMMUTABLE for forced signals"
"signal: Replace force_fatal_sig with force_exit_sig when in doubt"
both has the info:
"Unfortunately this broke debuggers[1][2] which reasonably expect to be able to trap synchronous SIGTRAP and SIGSEGV even when the target process is not configured to handle those signals."
and the second even has: "This avoids userspace regressions as older kernels exited with do_exit which debuggers also can not intercept."
or is the patch description on the second patch somewhat misleading ?
It is the same problem. But it only applies to code that was merged post 5.15.
For 5.15 on force_sig_seccomp is really affected.
For 5.16 there were many calls to do_exit that I turned into signals. Some of the properly should be oridinary signals and some of them for correctness purposes can't allow debuggers or userspace to intercept them.
The second patch went through and modified everything that was non-interceptible before 5.16 to be non-interceptible in 5.16. Where that is not necessary we can relax things later.
But for 5.15 only the one patch needs to be applied.
Eric
Thanks for the explanation.
--
Thomas