cfi: Store type erasure witness for Argument

[maurer]

This is a WIP that won't work until @rcvalle has fixed address-taken trait functions #115953 but I understand he has a fix for that on the way.

Once that's out of the way, this addresses #115199 point 2.

CFI/KCFI work by enforcing that indirect function calls are always called at the type they were defined at. The type erasure in Argument works by casting the reference to the value to be formatted to an Opaque and also casting the function to format it to take an Opaque reference.

While this is ABI safe, which is why we get away with it normally, it does transform the type that the function is called at. This means that at the call-site, CFI expects the type of the function to be fn(&Opaque, even though it is really fn(&T, for some particular T.

This patch avoids this by adding cast_stub, a witness to the type erasure that will cast the &Opaque and fn(&Opaque back to their original types before invoking the function.

This change is guarded by the enablement of CFI as it will require an additional pointer-sized value per Argument, and an additional jump during formatting, and we'd prefer not to pay that if we don't need the types to be correct at the indirect call invocation.

[rustbot]

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #123819) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC]

this is no longer blocked as the issue it was blocked on is resolved. marking this as on-author so that @maurer can resolve the conflicts and we can push this forward

[maurer]

I've resolved the conflict, but in manual testing, found that while this makes println! work with CFI enabled in the standard library, it still fails with KCFI enabled. I'd like to track that down before putting this in. My current primary suspect is that we may be getting the abstract type tag rather than the concrete one since I don't see the shim I expect in the output, but I haven't proved this or understood why yet (we do have a test that ensures the shim gets generated in some simpler cases).

Testing summary of the situation after this commit - dev is a link to a build of the compiler with this commit:

Program:

mmaurer@anyblade:~/github/rust-lang/print-example$ cat src/main.rs 
fn main() {
    println!("Hello, world! {:?}", std::env::args().collect::<Vec<_>>());
}

KCFI, with the patch, failing

mmaurer@anyblade:~/github/rust-lang/print-example$ RUSTFLAGS="-Zsanitizer=kcfi -Zsanitizer-cfi-normalize-integers -C panic=abort" cargo +dev run -Zbuild-std=panic_abort,std -Zbuild-std-features --release --target x86_64-unknown-linux-gnu
/* CUT */
     Running `target/x86_64-unknown-linux-gnu/release/print-example`
Illegal instruction

CFI, before the patch, failing

mmaurer@anyblade:~/github/rust-lang/print-example$ RUSTFLAGS="-Ccodegen-units=1 -Clinker-plugin-lto -Zsanitizer=cfi -Zsanitizer-cfi-normalize-integers" cargo +nightly run -Zbuild-std -Zbuild-std-features --release --target x86_64-unknown-linux-gnu
/* CUT */
     Running `target/x86_64-unknown-linux-gnu/release/print-example`
Illegal instruction

CFI, after the patch, succeeding

mmaurer@anyblade:~/github/rust-lang/print-example$ RUSTFLAGS="-Ccodegen-units=1 -Clinker-plugin-lto -Zsanitizer=cfi -Zsanitizer-cfi-normalize-integers" cargo +dev run -Zbuild-std -Zbuild-std-features --release --target x86_64-unknown-linux-gnu
/* CUT */
     Running `target/x86_64-unknown-linux-gnu/release/print-example`
Hello, world! ["target/x86_64-unknown-linux-gnu/release/print-example"]

[RalfJung]

FWIW I am not very happy about this. If what fmt does is well-defined behavior, then it is Not Great to have CFI reject such code -- presumably other crates in the ecosystem will also do this, making it very hard to just turn on CFI in a Rust binary and expect it to work out-of-the-box. OTOH if we consider what fmt does here to be not well-defined (either UB or at least erroneous behavior), then we should change what std does always, not just under a cfg.

Changing what the standard library does under cfg(sanitize) or cfg(miri) or similar flags is highly suspect as it means that the code being sanitized is not the code people usually run.

EDIT: I opened an issue for the wider discussion here: #128728