WIP: Use BTI c in aarch64_outline_atomic.rs

[taiki-e]

Potential fix for rust-lang/rust#151486.

TODO:

• Does this approach work in naked_asm?
• How to test this on CI? Both linux and macos runner by GitHub doesn't seem to support BTI.

[tgross35]

Thanks for jumping on this

How to test this on CI? Both linux and macos runner by GitHub doesn't seem to support BTI.

@rust-lang/project-exploit-mitigations any chance you have some testing ideas?

Does BTI work in qemu-user by chance?

[zmodem]

grep'ing compiler-builtins, I don't see any mention of bti at all. Maybe instead of adding hint #34 to each function manually, there should be some general facility which adds BTI landingpads to manually generated functions when the feature is enabled.

[taiki-e]

For normal Rust functions, the BTI c should be inserted by the compiler as needed. For global assemblies, the BTI c should be explicitly written within the assembly as needed.

However, it is unclear whose responsibility it should be for naked functions (what we use for outline_atomic). At least currently, the naked function does nothing, but -Z branch-protection is unstable so we can change its behavior.
cc @Amanieu @folkertdev

[folkertdev]

I think cfg_select would be nicer here

Suggested change

	#[cfg(all(branch_protection = "bti", branch_protection = "pac-ret"))]
	".word 3",
	#[cfg(all(not(branch_protection = "bti"), branch_protection = "pac-ret"))]
	".word 2",
	#[cfg(all(branch_protection = "bti", not(branch_protection = "pac-ret")))]
	".word 1",
	#[cfg(all(not(branch_protection = "bti"), not(branch_protection = "pac-ret")))]
	".word 0",
	cfg_select! (
	all(branch_protection = "bti", branch_protection = "pac-ret") => ".word 3",
	branch_protection = "pac-ret" => ".word 2",
	branch_protection = "bti" => ".word 1",
	_ => ".word 0",
	),

[folkertdev]

I'm not that familiar with how this works, but generally the aim is to make naked functions "just work". So I'd say naked functions should support the flag.

[zmodem]

There was some discussion about naked functions vs. bti on the llvm side: llvm/llvm-project#56369 but it didn't conclude. I'm not actually sure what the current behavior is.

[folkertdev]

Rust naked functions are entirely distinct from LLVM naked functions. We lower them to a block of global assembly + an extern block defining the rust symbol ourselves. So, we are free to make our own decisions here. So far, this flag was not considered, but it seems like we should.

[Amanieu]

I would actually prefer not having a BTI automatically inserted at the start of naked functions. The main purpose of naked functions is to support custom calling conventions which cannot be otherwise supported by the Rust compiler. In those cases we don't want to mess with what the user is intending for these functions to contain.

[folkertdev]

Ah, I misunderstood: this actually adds instructions. Then I agree that we should not add that. And then -Z branch-protection should provide a way (via cfg maybe?) for the program to know what mode it's being compiled in.

[Amanieu]

Is there any reason these functions need to be naked at all? They don't use a custom calling convention and could just be implemented using plain asm!. This would avoid any issues related to branch protection.

[tgross35]

Did a small sanity check and I think inline asm should be reasonably feasible https://rust.godbolt.org/z/s38z6a6jP. Might be a better way to still keep the early ret rather than jumping?

I was originally a bit concerned about paying for frame pointers, which used to be a bit of a problem with fma. But it looks like that has been resolved with rust-lang/rust#141800.

[Amanieu]

You could write the LSE check in normal rust code and have 2 separate asm blocks in different if branches.