6 ms·

Panicking (unwinding) across an FFI boundary is very much undefined behaviour. You'd get analogous cross language issues with C++ exceptions. Or mixing GCC ABI

by orra 6y ago

Panicking (unwinding) across an FFI boundary is very much undefined behaviour. You'd get analogous cross language issues with C++ exceptions. Or mixing GCC ABI unwinding with MSVC ABI unwinding. Nonetheless, there is a working group, proposing to make it defined under certain circumstances. https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind-design-meeting.html https://blog.rust-lang.org/inside-rust/2020/02/27/ffi-unwind...

e12e 6y ago
But is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) - or undefined behavior in the sense that it should crash - but might return?
- orra 6y ago
  I’m not sure I'd draw a distinction. People used to say you should initialise your variables in C89 to NULL, so you'd get a crash if you forget to properly set the variable. But enough security bugs have been caused by null pointer dereferences. In the Rust case, IIRC, Rust annotates functions with the LLVM attribute no_unwind. I'd expect bad things, thanks to optimisation passes, if an unwind were to start. Doubly so if mixing GCC with MSVC ABI.
- nicoburns 6y ago
  > is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) Yes.
e12e 6y ago
Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.
- Tobu 6y ago
  There are two options at the moment [1]: - panic=abort (uncatchable) - panic=unwind. With the latter, you would need a catch_unwind at the FFI boundary. [1] https://doc.rust-lang.org/cargo/reference/profiles.html#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
  - e12e 6y ago
    I see. I would think that for a library, in production, all you'd want for panic was a crash. (I guess this is the abort case). AAre the panics being discussed for removal in rust tls "soft" errors that should not crash?
    - Tobu 6y ago
      There's a categorization here (I don't have access to the triage spreadsheet though): https://github.com/ctz/rustls/issues/447#issuecomment-820719957 https://github.com/ctz/rustls/issues/447#issuecomment-820719... It seems like there's been the most effort on category 4, the ones that can't be reached but can often be proven away with refactoring and typestate. Removing these ensures that the APIs don't expose Result types to callers unnecessarily. Category 1-3 have different severity, but they are all planned to be folded into Result error values.

by orra 6y ago

e12e 6y ago

But is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) - or undefined behavior in the sense that it should crash - but might return?

orra 6y ago
I’m not sure I'd draw a distinction. People used to say you should initialise your variables in C89 to NULL, so you'd get a crash if you forget to properly set the variable. But enough security bugs have been caused by null pointer dereferences. In the Rust case, IIRC, Rust annotates functions with the LLVM attribute no_unwind. I'd expect bad things, thanks to optimisation passes, if an unwind were to start. Doubly so if mixing GCC with MSVC ABI.
nicoburns 6y ago
> is this undefined behavior in the typical c sense (lol, I see you call function possibly_undefined() I'll just make you a sandwich and clobber all registers instead) Yes.

e12e 6y ago

Thank you for that link, I thought (production build) rust panic was simply a core dump. I didn't realize there was stack unwinding going on.

Tobu 6y ago
There are two options at the moment [1]: - panic=abort (uncatchable) - panic=unwind. With the latter, you would need a catch_unwind at the FFI boundary. [1] https://doc.rust-lang.org/cargo/reference/profiles.html#panic https://doc.rust-lang.org/cargo/reference/profiles.html#pani...
- e12e 6y ago
  I see. I would think that for a library, in production, all you'd want for panic was a crash. (I guess this is the abort case). AAre the panics being discussed for removal in rust tls "soft" errors that should not crash?
  - Tobu 6y ago
    There's a categorization here (I don't have access to the triage spreadsheet though): https://github.com/ctz/rustls/issues/447#issuecomment-820719957 https://github.com/ctz/rustls/issues/447#issuecomment-820719... It seems like there's been the most effort on category 4, the ones that can't be reached but can often be proven away with refactoring and typestate. Removing these ensures that the APIs don't expose Result types to callers unnecessarily. Category 1-3 have different severity, but they are all planned to be folded into Result error values.