Re: FAILED: patch "[PATCH] signal: Don't always set SA_IMMUTABLE for forced signals" failed to apply to 5.15-stable tree

[ebiederm@xmission.com (Eric W. Biederman)]

Thomas Backlund <tmb@iki.fi> writes:

> Den 2021-11-23 kl. 21:24, skrev ebiederm@xmission.com:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>>
>>> On Tue, Nov 23, 2021 at 07:29:43PM +0200, Thomas Backlund wrote:
>>>> Den 2021-11-22 kl. 14:31, skrev gregkh@linuxfoundation.org:
>>>>> The patch below does not apply to the 5.15-stable tree.
>>>>> If someone wants it applied there, or to any other stable or longterm
>>>>> tree, then please email the backport, including the original git commit
>>>>> id to <stable@vger.kernel.org>.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> It will apply if you add this one first:
>>>>
>>>>  From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>>
>>>>
>>>>
>>>>
>>>> and if the other patch for signal that has similar description should land
>>>> in 5.15:
>>>>
>>>>  From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>>> doubt
>>>>
>>>>
>>>>
>>>> then the list is looks something like:
>>>>
>>>>
>>>>  From 941edc5bf174b67f94db19817cbeab0a93e0c32a Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:00 -0500
>>>> Subject: [PATCH] exit/syscall_user_dispatch: Send ordinary signals on
>>>> failure
>>>>
>>>>  From 83a1f27ad773b1d8f0460d3a676114c7651918cc Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:53 -0500
>>>> Subject: [PATCH] signal/powerpc: On swapcontext failure force SIGSEGV
>>>>
>>>>  From 9bc508cf0791c8e5a37696de1a046d746fcbd9d8 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:57 -0500
>>>> Subject: [PATCH] signal/s390: Use force_sigsegv in default_trap_handler
>>>>
>>>>  From c317d306d55079525c9610267fdaf3a8a6d2f08b Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:01 -0500
>>>> Subject: [PATCH] signal/sparc32: Exit with a fatal signal when
>>>>   try_to_clear_window_buffer fails
>>>>
>>>>  From 086ec444f86660e103de8945d0dcae9b67132ac9 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:02 -0500
>>>> Subject: [PATCH] signal/sparc32: In setup_rt_frame and setup_fram use
>>>>   force_fatal_sig
>>>>
>>>>  From 1fbd60df8a852d9c55de8cd3621899cf4c72a5b7 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:56 -0500
>>>> Subject: [PATCH] signal/vm86_32: Properly send SIGSEGV when the vm86 state
>>>> cannot be saved.
>>>>
>>>>  From 695dd0d634df8903e5ead8aa08d326f63b23368a Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:44:03 -0500
>>>> Subject: [PATCH] signal/x86: In emulate_vsyscall force a signal instead of
>>>> calling do_exit
>>>>
>>>>  From 26d5badbccddcc063dc5174a2baffd13a23322aa Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Wed, 20 Oct 2021 12:43:59 -0500
>>>> Subject: [PATCH] signal: Implement force_fatal_sig
>>>>
>>>>  From e21294a7aaae32c5d7154b187113a04db5852e37 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Mon, 25 Oct 2021 10:50:57 -0500
>>>> Subject: [PATCH] signal: Replace force_sigsegv(SIGSEGV) with
>>>>   force_fatal_sig(SIGSEGV)
>>>>
>>>>  From e349d945fac76bddc78ae1cb92a0145b427a87ce Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 11:11:13 -0600
>>>> Subject: [PATCH] signal: Don't always set SA_IMMUTABLE for forced signals
>>>>
>>>>  From fcb116bc43c8c37c052530ead79872f8b2615711 Mon Sep 17 00:00:00 2001
>>>> From: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Date: Thu, 18 Nov 2021 14:23:21 -0600
>>>> Subject: [PATCH] signal: Replace force_fatal_sig with force_exit_sig when in
>>>> doubt
>>>>
>>>>
>>>>
>>>> Applying them in listed order on top of 5.14.4 and builds/runs on i586,
>>>> x86_64, armv7hl, aarch64
>>> That series list is crazy, let me go try it and see what blows up! :)
>> 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.

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