SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 18, 2021 20:00 UTC (Sat) by NYKevin (subscriber, #129325)
Parent article: SA_IMMUTABLE and the hazards of messing with signals

If a signal falls in the forest, but nobody can hear it, does it make a sound?

More prosaically, what exactly is the *observable* difference between sending a signal that can't be caught or ignored, and "faking it?" If there is no observable difference, why bother?

This is a genuine question, not a rhetorical "they wasted a bunch of time" argument. I don't know enough about the kernel's internals to answer it for myself.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 18, 2021 21:42 UTC (Sat) by matthias (subscriber, #94967) [Link] (1 responses)

I just quote Eric from this (https://lwn.net/ml/linux-kernel/87sfwqxv8g.fsf@disp2133/) mail:

> The why is that do_exit as an interface needs to be refactored.
>
> As it exists right now "do_exit" is bad enough that on a couple of older
> architectures do_exit in a random location results in being able to
> read/write the kernel stack using ptrace.
>
> So to addresses the issues I need to get everything that really
> shouldn't be using do_exit to use something else.

Also it seems that there is indeed a difference: The "fake signal and do_exit()"-approach only terminates a single thread, however the signal should bring down the whole process.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 23, 2021 4:51 UTC (Thu) by mmirate (guest, #143985) [Link]

> Also it seems that there is indeed a difference: The "fake signal and do_exit()"-approach only terminates a single thread, however the signal should bring down the whole process.

Ah, so *that* is why my multithreaded program isn't working on new kernels anymore. Whenever each thread finished its assigned work, it would clean itself up by committing a seccomp violation. Very annoying I have to change the program now. I'm going to complain on the mailing list.