Den 2021-11-23 kl. 23:41, skrev ebiederm@xxxxxxxxxxxx:
Thomas Backlund <tmb@xxxxxx> writes:
Den 2021-11-23 kl. 21:24, skrev ebiederm@xxxxxxxxxxxx:
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
