"C-unwind" ABI is unsound with "-Cpanic=abort"

[RalfJung]

In the following code, test should explicitly be allowed to unwind:

#![feature(c_unwind)]

extern "C-unwind" {
    fn test();
}

fn main() {
    unsafe { test(); }
}

However, when building this with -Cpanic=abort, we generate LLVM IR as follows:

; Function Attrs: nounwind nonlazybind
declare void @test() unnamed_addr #1

This means unwinding of test is UB, i.e., this is a soundness problem.

This most likely also affects #[unwind(allowed)], but that attribute is slated for removal anyway.

[apiraino]

Assigning P-medium since still a nightly-only feature. Discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

@rustbot label -I-prioritize +P-medium

[cratelyn]

I'll look into a fix for this, as the author of #76570, which introduced this issue. Thank you for flagging this @RalfJung.

[nagisa]

This is probably pretty hard to fix in a way that affects least amount of code negatively.

Any function that may at any point, directly or indirectly, end up calling a C-unwind function must not be annotated with a nounwind. It can't be known in general case that this is true, this knowledge could only be available at binary load time.

So AFAICT the only viable fixes here are:

• just don't annotate anything with nounwind, ever, -Cpanic=abort or not (we can still replace invokes with calls though);
• annotate leaf functions (functions that don't call anything else) as nounwind and then any functions that only call other nounwind functions as nounwind.

The latter is something LLVM is already capable of inferring by itself, so there's probably little value in doing it in rustc. Maybe later, once or if MIR optimisations start caring about this, I guess?

[RalfJung]

There's another possible fix: wrap imported extern "C-unwind" functions in a wrapper that turns unwinding into aborts. Rust code calling the function all goes through that wrapper. Then the nounwind is actually correct.

[nagisa]

We cannot do that, I think. Rust has no idea what the correct personality function would be to "catch" the unwinds from the other side of FFI. Also, isn't the intent that in situations where "C calls Rust calls C" unwinding across POF Rust frames is a supported use-case?

[bjorn3]

There is no "correct" or "wrong" personality function to catch unwinds. Any personality function is allowed to catch any non-forced unwind. The panic_abort crate could define a personality function that always aborts when not generating a backtrace. If the wrapper function or any function directly calling "C-unwind" without wrapper doesn't use nounwind, any attempt at unwinding through rust code would abort.