SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 19, 2021 22:18 UTC (Sun) by roc (subscriber, #30627)
In reply to: SA_IMMUTABLE and the hazards of messing with signals by marcH
Parent article: SA_IMMUTABLE and the hazards of messing with signals

The forcing behavior makes sense where it's used. For example if a process ignores/masks SIGILL and then executes an illegal instruction, that cannot really be "ignored", so there's no obviously better alternative to the kernel's approach unblocking the signal and then delivering it.

to post comments

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 19, 2021 23:03 UTC (Sun) by marcH (subscriber, #57642) [Link] (11 responses)

> For example if a process ignores/masks SIGILL and then executes an illegal instruction, that cannot really be "ignored", so there's no obviously better alternative to the kernel's approach unblocking the signal and then delivering it.

So why can SIGILL be ignored in the first place?

This ignore/force "arms race" demonstrates the lack of clear, top-down classification of signals. For instance the fact that SIGKILL cannot be ignored is always mentioned "in passing" deep down in the SIGKILL-specific section. That always struck me as incredibly bad documentation and/or design: the distinction between signals that can be ignored versus not should be made _at the very top_ with further subsections for the various other classes of signals-that-can-be-ignored-except-when-not. In fact they should even have different prefixes, I mean SIGKILL should not even be called SIGKILL but something else like UNMASKABLE_KILL.

> The forcing behavior makes sense where it's used.

And what is the formal definition of "makes sense where it's used"? As long as there's none, race conditions and unanticipated corner cases will keep happening. Do we still need proof in 2021 that concurrency is hard and requires very careful and formal design? I heard that the high level design of signals was botched 50 years ago but Linux is now in a unique, quasi-monopolistic position to clean things up without caring about portability. However this requires a whiteboard and some computer _science_, not everything can be solved with a hands-on, incremental, "send patches" approach.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 4:40 UTC (Mon) by roc (subscriber, #30627) [Link] (7 responses)

This is almost entirely unrelated to concurrency so I'm not sure why you're bringing that up.

> So why can SIGILL be ignored in the first place?

Yes, arguably it shouldn't be ignorable. However, it does make sense to install a signal handler for SIGILL (e.g. to emulate the instruction or recover in some other way). I don't know the history of the development of Unix signal handling, but it's easy to imagine that once signal handlers were invented, it was convenient to use a single mechanism for both async signals (e.g. SIGINT, SIGTERM) and "deterministic" signals such as SIGILL and SIGSEGV.

I certainly agree that when we look at what signals and signal handling have evolved into, the design looks pretty nasty.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 6:54 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

> This is almost entirely unrelated to concurrency

When you need exclusive access to some data, there is not much difference between 1. another thread accessing the data concurrently on a different core 2. another thread/handler pausing you to access the data on the same core. The concepts and tools are the same and people usually try to write code that handles both cases indifferently.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 11:15 UTC (Mon) by roc (subscriber, #30627) [Link] (1 responses)

> The concepts and tools are the same

I don't agree with this at all. Signal-safety and thread-safety are actually very different concepts with very different constraints. For example, you can make code thread-safe by using mutexes, but that actually doesn't work at all for signal handlers because you will instantly deadlock if a signal handler tries to acquire a mutex held by the thread it interrupted (assuming non-reentrant mutexes; if your mutexes are reentrant the situation is even worse since you won't get mutual exclusion).

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 16:14 UTC (Mon) by marcH (subscriber, #57642) [Link]

Please try to describe the problems and solutions using concepts and terms not used when dealing with concurrency.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 21, 2021 14:34 UTC (Tue) by jrtc27 (subscriber, #107748) [Link] (3 responses)

To add to the ways in which OpenSSL is a terrifying piece of software, it also installs a SIGILL handler in order to probe hardware features on Arm. Most are covered by AT_HWCAP* these days, but apparently not all, at least on 32-bit Arm. This makes debugging OpenSSL-using software particularly fun on Arm, since it breaks on the SIGILL during initialisation, and you have to continue past it.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 23, 2021 19:38 UTC (Thu) by pm215 (subscriber, #98099) [Link] (2 responses)

Using SIGILL for that on Arm is a bad idea which has been disrecommended for more than a decade (the alternatives today being hwcaps or directly reading the ID registers, which the kernel trap-and-emulates). There is at least one case I know of where trying an insn might succeed without causing a SIGILL but where it is not safely available for userspace. (To be fair, that case is a bit old and obscure now -- a few early Cortex-A8 based boards had issues with Neon, so the kernel reported "no Neon" to userspace, but since there was no way to make Neon trap separately from VFP, code that took the "see if it SIGILLs" approach would get the wrong answer.)

On the bright side, openssl seems to skip all but one of the SIGILL tests if it can get the hwcaps through getauxval. Maybe the kernel needs to grow another hwcap for that last test?

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 29, 2021 3:22 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

There are also arm devices which have heterogeneous sets of CPU cores, e.g. it might have two armv8.0 and two armv8.2 cores available.

The kernel hwcaps mechanism ensures that only the capabilities available on all cores are reported available (modulo buggy kernels, sigh). But, if you ignore that, and just try executing instructions to see what looks like it works, you'll be in for a bad time when your process happens to get moved to a different core with fewer instructions available later on.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 30, 2021 17:24 UTC (Thu) by pm215 (subscriber, #98099) [Link]

Yeah, I thought of the heterogenous-cluster case, but I couldn't remember whether the kernel reported a lowest-common-denominator hwcaps or just flatly refused to boot (as a "don't do this silly thing" hint to hardware designers :-)), so I didn't mention it.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 4:42 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

> Linux is now in a unique, quasi-monopolistic position to clean things up without caring about portability.

Linux does have to care about compatibility though, so at this point creating something brand-new in place of signals would only increase complexity since the existing signal system would still need to be supported.

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 7:01 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

I wrote "clean things up", not "something brand new". I meant: clean up the documentation, add a couple cleaner APIs while keeping the old ones for backward compatibility, define and document undefined behaviors, explicitly forbid the sequences that never worked... I think design decisions like these already happened in other, dark POSIX areas?

SA_IMMUTABLE and the hazards of messing with signals

Posted Dec 20, 2021 11:15 UTC (Mon) by roc (subscriber, #30627) [Link]

Sure, I guess, but it's not clear to me you can make things much better this way.