Serious vulnerability fixed with OpenSSH 9.8

Yeah. Windows deals with these signals using SEH (Structured Exception Handling) which is only slightly better than signals.

In theory, a signal can be split into two primitives:
1. Pause the offending process (SIGSTOP?).
2. Notify the handler running in a separate thread (or process) to handle the condition.

Having an explicit "paused" state is actually a good primitive in itself, and might be useful for other purposes (e.g. for a better process launch API). It's not _entirely_ better, you still have to deal with functions that might be terminated at a basically arbitrary point. But at least it reduces the asynchronous suspension problem to more well-known multithreading.

Signals like SIGWINCH, SIGINT, SIGTSTP, SIGCHLD, SIGUSR1, etc. should be processed by a signal handler that does as little as possible and defers the work back to the main part of the program. If you wish, you can also defer the execution of the signal handler itself.

Signals like SIGSEGV, SIGFPE, etc. are genuinely hard to handle. You cannot use async-signal-unsafe / non-reentrant code to handle them, in the colloquial sense of "handle" as in "respond to": the signal handler is called at an arbitrary point that you cannot guarantee is not in the middle of some problematic function (or even between two CPU instructions implementing a single logical operation, like writing to a long-enough integer), and you have no ability to defer handling it. You need to be careful and there's no real way around it. In practice, for most programs the only useful thing to do is to print a backtrace or similar error message and exit, and you should just find some library that is designed for this purpose and can print a backtrace without any async-signal-unsafe calls. (For some very carefully designed programs e.g. in a managed runtime, you might be able to unwind the managed stack via unmanaged code, or inject a stack frame to perform unwinding and return to that, but now you're talking about something very different from OpenSSH as it exists today.)

(And of course I am putting aside the possibility of raising SIGSEGV etc. manually, which is deeply silly but means this particular signal is more like the first category - you can meaningfully block such a signal and receive it later.)

There are also two signals which in my opinion should not be caught at all - SIGPIPE and SIGFSZ. Both of these signals have the property that the default disposition terminates the process, and they otherwise cause specific errnos to be returned, EPIPE and EFBIG. The default disposition is useful for ease of programming (e.g., SIGPIPE causing the process to silently terminate means that `yes | head` works the way you want with the obvious implementations of both commands), but if you're going to handle it yourself, you can just ignore the signals and handle the errno from write() - there's no advantage in handling it in a separate part of the code. While you can defer handling the signals, the calling code will have already gotten EPIPE/EFBIG, so it doesn't seem particularly useful to handle them asynchronously.

My position is that signal handlers should not do any nontrivial work at all, and ideally not call any functions at all - they should just store data into a preallocated buffer of some sort (which could be a simple flag or counter, if you don't need any metadata sent with the signal) and return immediately. If you absolutely must, you can call write(2) and no other functions, either to do a self-pipe or to stderr. If you need to abort the program, you can also call _exit(2) (not exit(3)!). That's it.

If you're doing any amount of work in the signal handler, there is too much risk of calling an async-signal-unsafe function (e.g., syslog) because you start thinking of it as a normal function - or, as OpenSSH did, because you call other normal functions in other files that are async-signal-safe today but might not be tomorrow.

Your position, as I understand it (and please correct me if I'm wrong) is that it's actually fine for signal handlers to call functions that aren't async-signal-safe, provided that you make sure that the signals are blocked while any such functions might be running and only unblocked when any such functions are complete. I argue this is no less dangerous; just like how, in a complicated program, you might take a complicated function that only calls async-signal-safe functions and introduce an async-signal-unsafe call without realizing what you're doing, you might also unblock a signal (e.g. by calling pselect() or something) from inside async-signal-unsafe / non-reentrant code without realizing what you're doing. In the example here of using alarm() to interrupt a connection after a timeout, it is quite plausible that someone might find that the alarm isn't being delivered as promptly as needed and unblock SIGALRM in an unsound way to solve the bug.

I am in agreement with you that you should impose a rule on the programmer that a complicated response to a signal should be executed at a time when it is not interrupting other work in the program. My claim is there's a straightforward way for the programmer to abide by this rule: reuse the mechanisms that the program already has for making sure that responses to other external events - i.e. I/O - are executed without interrupting other work in the program, whatever that mechanism is. If it's an event loop managing non-blocking code, hook into the event loop. If it's straight-line code doing I/O, check for EINTR and see if a flag got flipped.

By not introducing a new type of control flow (essentially a COME FROM!), the question of how to get that control flow right disappears. UNIX signal handlers don't give you a way to fully avoid the change in control flow, but if your signal handler just writes to a variable (atomically/consistently) and returns, then you are as close as possible to avoiding the change in control flow.

Another totally reasonable option, instead of a minimal signal handler, is to make a dedicated signal-handling thread that sits in sigwaitinfo() and then uses thread-safe mechanisms to convey receipt of the signal back to the main thread. This actually does avoid any change in control flow - assuming your program is already multi-threaded. If a program is currently single-threaded, then you can't actually fully handle the signal in the new signal-receiving thread because the data structures you will use to do so probably aren't thread-safe, so there's no particular advantage over having a minimal signal handler, so you'll have to resist the temptation to do anything other than, again, writing to some thread-safe data structure (e.g., pthread_cond_signal) and going back to sigwaitinfo().

Annoyingly, it has to acquire the GIL before it can execute the signal handler, and even more annoyingly, it tries to handle SIGINT by default, so (in extreme cases) Python can hang for several seconds between pressing ^C and the process actually terminating, even if the programmer made no attempt to handle any signals. Fortunately, it does not try to handle SIGQUIT, so you can just press ^\ instead of ^C.

SDL hooks signals so it can clean up after itself properly. That can be disabled at init time.

It also generates signals and expects the application to supply a callback to handle them in a realtime manner -- This is notably used in SDL's audio subsystem, and is also one of the approaches supported by ALSA.

It also uses signals in its internal threading implementation.

All of this was true in the SDL1 days; I don't know if SDL2 or beyond does things differently.

But as I mentioned above, ALSA can use signals as one of three mechanisms for informing applications to refill audio buffers. (the other two being blocking I/O and non-blocking select/poll-based I/O). Which one you use depends on how your application is structured.