Unsoundness when a panic Rust code is caught by separetely compiled Rust code through FFI-unwind

[nbdd0121]

Rust code might be able to catch foreign Rust code through FFI unwind.

a.rs:

#![crate_type = "cdylib"]
#![feature(c_unwind)]

#[no_mangle]
extern "C-unwind" fn panic() {
    panic!();
}

b.rs:

#![feature(c_unwind)]

#[link(name = "a")]
extern "C-unwind" {
    fn panic();
}

fn main() {
    let err = std::panic::catch_unwind(|| {
        unsafe { panic() };
    });
    match err {
        Err(v) => {
            // Able to access `Box<dyn Any>` generated by another
            // compiler; we can't guarantee that typeid does not conflict
            // across Rust versions, nor that the vtable format is
            // stable.
			// EDIT: Also this will result a `Box` allocated in one allocator
			// from being deallocated in another, which is more obviously unsound.
        }
        _ => (),
    }
}

These two crates could be compiled with different Rust versions, or same version with different flags (e.g. struct layout randomisation), and this will create unsoundness because we couldn't guarantee the ABI for separate compilations.

Currently we just use the exception class in the unwind runtime ("MOZ\0RUST") to tell apart Rust exceptions from foreign exceptions, but for soundness we need to treat Rust exception from another compilation as foreign exception as well.

[nbdd0121]

@rustbot label: +F-c_unwind +WG-project-ffi-unwind +I-unsound +requires-nightly +A-ffi +A-runtime

[nbdd0121]

I think it's worth mentioning that catching a foreign unwind in Rust is UB. I mark this as I-unsound because:

1. We don't have a clear documentation about the situation of Rust code being foreign code.
2. We are currently not guarding against it.
3. It might work by mistake without anyone noticing.

While guarding against it is favorable, this issue could be considered solved if we simply document clearly that this kind of situation is same as catching a non-Rust (e.g. C++) foreign unwind, which is UB.

[DemiMarie]

I think it's worth mentioning that catching a foreign unwind in Rust is UB.

I would like to see this somewhat changed in the future. Specifically, I would like:

• Throwing e.g. a C++ exception across Rust stack frames causes Rust destructors to be called.
• A Rust panic that unwinds into C++ causes C++ destructors to be called.
• Cross-language exception objects are completely opaque: one can drop them (which will call its destructor, if applicable) or rethrow them, but (without directly interacting with the foreign language’s runtime) one cannot obtain any information about the exception.

That would likely require a separate RFC, though.

[bjorn3]

or rethrow them

You can't rethrow foreign exceptions without hooking directly into the runtime of the respective language when catching them and when rethrowing them. libstd can't hook into the C++ standard library, so rethrowing after std::panic::catch_unwind is out of the question.

Throwing e.g. a C++ exception across Rust stack frames causes Rust destructors to be called.
A Rust panic that unwinds into C++ causes C++ destructors to be called.

Unwinding through C++ or Rust already causes destructors to run. It is only the catching that isn't allowed.

[RalfJung]

, this issue could be considered solved if we simply document clearly that this kind of situation is same as catching a non-Rust (e.g. C++) foreign unwind, which is UB.

Yeah this makes sense to me. Do we have any documentation talking about linking together Rust code compiled with different toolchains? We already obviously don't allow passing repr(Rust) types between them, they have to use FFI-safe types, so arguably it is only consistent to say the same about unwinding.

[bjorn3]

Rust panics pass a Box<dyn Any + Send> around (passed to panic_any and resume_unwind and returned from catch_unwind) which is not FFI safe, so we shouldn't need to have an extra rule specifically for panics.

[nbdd0121]

The problem is that there are no explicit use of Box<dyn Any + Send>. The example code in the OP exhibits UB in a quite subtle way.