CFI: core and std have explict CFI violations

[rcvalle]

Even though the user can now rebuild both core and std with CFI enabled (see #90546) using Cargo build-std feature (which is recommended), both have explicit CFI violations that prevent the compiled program from functioning with CFI enabled.

So far, I've identified three CFI violations:

1. std::sys::unix:thread_local_dtor::register_dtor weakly links __cxa_thread_atexit_impl and and the Rust compiler currently omits weakly function definitions and its metadata from LLVM IR.
2. core::fmt::rt::Argument transmuting formatter in new and indirectly branching to/calling it in fmt.
3. Rust's "try catch" construct (i.e., std::panicking::r#try) use of FnOnce explicitly violating CFI .
4. std::sys::unix::weak::syscall macro weakly links functions and the Rust compiler currently omits weakly function definitions and its metadata from LLVM IR.

I'm not sure if those are all CFI violations, but all core and std tests pass after disabling CFI in those locations with the no_sanitize attribute.

[workingjubilee]

I'm concerned about transmuting to a more refined type being rejected by LLVM's type-directed CFI. Specifically,

• from a function that accepts "thin-pointers to anything", i.e.
  • fn(*mut c_void) aka void(void*)
• to a function that accepts "thin-pointers to something specific" e.g.
  • fn(*mut u8) aka void(unsigned char*)

Intuitively, because void* must have an identical representation as char*, even though it is technically not a "compatible type" according to C (as void* is an incomplete type), refining the function's argument types should be permitted. And indeed casting a pointer from AnyOneThing* to void* and then back to AnyOneThing* should work.

I realize it may be unpleasant, but the reason why Rust does this?

https://www.youtube.com/watch?v=Y-Elr5K2Vuo

Rust's std puns between u8 and c_void like this because of LLVM insisting that a C void* is equivalent to an LLVMIR i8*. Thus Rust adopted this idiom of treating a byte pointer as interchangeable with a void pointer, because they effectively are, and because it was necessary to convince LLVM to recognize certain special functions.

[ChrisDenton]

Related:

• c_void implementation
• c_void docs

[rcvalle]

Thank you for all the information, @workingjubilee and @ChrisDenton! LLVM CFI does support those patterns (as C and C++ also use those), the casts/transmutes just have to be adjusted at the indirect call sites. You can see what I just did for (1) in the PR. This is not a characteristic of LLVM CFI itself, but many fine-grained type-based CFI implementations that perform function pointer type testing at the indirect call site.

It's actually common for large code bases to have those CFI violations when CFI support is initially implemented. For example, the Linux kernel had many. I'm actually surprised I've found only three so far for core and std, and this is actually very good.