> Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe.
My understanding is that a sound implementation of signal handling in Rust will require the signal handler to be Send, requiring it only has access to shared data that is Sync (safe to share between threads). I guess thread-safe does not nessecarily imply signal-safe, though.
And of course you could still call to a signal-unsafe C function but that requires an unsafe block, explicitly acknowledging that Rust's guarentees do not apply.
Signal handlers are not threads. Rust doesn't have anything that expresses the special extremely restrictive requirements of signal handlers.
A safe-Rust thread-safe Send+Sync function is allowed to call `format!()`, or `Box::new`, or drop a `Vec`, all of which will directly cause the exact same vulnerability as in SSH.
There is nothing in Rust that can say "you can't drop a Vec", and there are no tools that will let you find out whether any function you call may do it. Rust can't even statically prove that panics won't happen. Rust's panic implementation performs heap allocations, so any Rust construct that can panic is super unsafe in signal handlers.
My understanding is that a sound implementation of signal handling in Rust will require the signal handler to be Send, requiring it only has access to shared data that is Sync (safe to share between threads). I guess thread-safe does not nessecarily imply signal-safe, though.
And of course you could still call to a signal-unsafe C function but that requires an unsafe block, explicitly acknowledging that Rust's guarentees do not apply.