Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect UB due to unwinding past extern "C" functions #1740

Closed
RalfJung opened this issue Mar 11, 2021 · 8 comments · Fixed by #1744
Closed

Detect UB due to unwinding past extern "C" functions #1740

RalfJung opened this issue Mar 11, 2021 · 8 comments · Fixed by #1744

Comments

@RalfJung
Copy link
Member

Even with rust-lang/rust#76570, I think it is possible to unwind past an extern "C" function by setting an #[unwind] attribute, and that is UB. We should make sure Miri detects that UB.

@RalfJung
Copy link
Member Author

Testcase that should be detected as UB my Miri:

#![feature(unwind_attributes)]

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

fn main() {
    std::panic::catch_unwind(|| unwind()).unwrap_err();
}

@bjorn3
Copy link
Member

bjorn3 commented Mar 11, 2021

https://github.com/rust-lang/rust/blob/b3ac52646f7591a811fa9bf55995b24fd17ece08/compiler/rustc_mir_build/src/build/mod.rs#L562-L567

#[unwind] is checked first. Only if no #[unwind] is found, is the abi checked.

@RalfJung
Copy link
Member Author

Yes, unwind(allowed) removes the abort-on-panic wrapper.

But that has no effect on UB, I presume? The RFC does not say that these attributes change the fact that unwinding past an extern "C" function is UB.

@bjorn3
Copy link
Member

bjorn3 commented Mar 11, 2021

I would assume that #[unwind] will eventually be removed. All uses of #[unwind(allowed)] in the standard library can be replaced with extern "C unwind"/extern "system unwind" as far as I know.

@RalfJung
Copy link
Member Author

I would assume that #[unwind] will eventually be removed.

That would make sense... I was wondering what the point of that attribute is. "Letting one cause UB" doesn't sound very convincing except when it comes to crafting Miri testcases. ;)

@RalfJung
Copy link
Member Author

This would still be UB though I think:

#![feature(c_unwind)]

extern "C-unwind" fn unwind() {
    panic!();
}

fn main() {
    let unwind: extern "C-unwind" fn() = unwind;
    let unwind: extern "C" fn() = unsafe { std::mem::transmute(unwind) };
    std::panic::catch_unwind(|| unwind()).unwrap_err();
}

The caller uses a non-unwinding ABI so it might not have cleanup blocks; unwinding anyway is thus UB.

@bjorn3
Copy link
Member

bjorn3 commented Mar 11, 2021

Yes, the MIR of the caller would omit cleanup blocks.

bors added a commit that referenced this issue Mar 14, 2021
ensure we catch incorrectly unwinding calls

Fixes #1740
@RalfJung
Copy link
Member Author

But that has no effect on UB, I presume? The RFC does not say that these attributes change the fact that unwinding past an extern "C" function is UB.

I since then learned that indeed it does affect UB; nounwind is suppressed when #[unwind(allowed)] is set.

@bors bors closed this as completed in a798792 Mar 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants