What are the opsem concerns around pointer authentication?

[RalfJung]

There is a pointer authentication project goal.. Are there any opsem questions we have to answer around pointer authentication, or is the idea that all UB-free Rust programs (including arbitrary UB-free unsafe code) will behave exactly as before?

I haven't yet found a description of pointer authentication that's written for people that don't care about the aarch64 details, everything is exceedingly low-level. The goal owner pointed me to https://llvm.org/docs/PointerAuth.html which is the most comprehensible description I found so far, though what is still missing is any idea when those operations are invoked by a Rust program. So based on that there are some first questions:

• It seems like llvm.ptrauth.sign alters the address bits of the pointer. What does that mean for things like dereferenceability? Are both the old and new pointer dereferenceable but point to the same memory? That seems pretty incompatible with our memory model. Does the old pointer become invalid when the intrinsic is called?
• Something happens with function pointer calls. Those are apparently also signed. Do we have to worry about introducing new ABI compatibility issues here, similar to what happened with CFI?

Cc @jchlanda

[bjorn3]

It seems like llvm.ptrauth.sign alters the address bits of the pointer. What does that mean for things like dereferenceability? Are both the old and new pointer dereferenceable but point to the same memory? That seems pretty incompatible with our memory model. Does the old pointer become invalid when the intrinsic is called?

Pointer signing adds a tag in the upper 8 bits of the pointer, which were otherwise required to be a sign extension of the remaining 52bit of the address that is actually used by the CPU (or on most CPUs actually only 48bit, with the entire upper 16bit required to be sign extended). When dereferencing a pointer, the compiler will emit an instruction to check that the tag is correct and then strip it. The signed pointer itself can't be directly loaded from at the CPU level, but unsigned pointers can't be loaded from at the Rust AM level. .addr() can strip the tag after authenticating the pointer. .with_addr() could authenticate the old pointer, strip the tag and then sign the new pointer. For exposed provenance, I think we did have to strip the tag and allow creating an arbitrary valid signed pointer. .with_addr() and exposed provenance would hurt effectiveness of pointer authentication as the address could be tampered with while it is not signed.

Something happens with function pointer calls. Those are apparently also signed. Do we have to worry about introducing new ABI compatibility issues here, similar to what happened with CFI?

For arm64 ELF pauth no. Different keys are used for function and data pointers, but otherwise all function pointers use the same key and all data pointers use the same key. Some pointers that should not be accessible for the user like return pointers do use different keys (+ possibly pointer location dependent salt), but that shouldn't matter.

For apple arm6e4, C++ vtable method pointers get signed with a different key that regular function pointers and a salt derived from the function signature according to https://developer.apple.com/documentation/security/preparing-your-app-to-work-with-pointer-authentication#Update-your-code-to-avoid-pointer-authentication-failures. Regular function pointers all use the same key without salt.

[RalfJung]

Thanks! That's the kind of stuff I wish the goal would have explained. :)

For arm64 ELF pauth no. Different keys are used for function and data pointers, but otherwise all function pointers use the same key and all data pointers use the same key. Some pointers that should not be accessible for the user like return pointers do use different keys (+ possibly pointer location dependent salt), but that shouldn't matter.

There is a function in rustc that computes a "discriminator" for a function signature, and it takes into account the actual function type. IIUC, not just the key but also the discriminator has to be the same. If fn(T) and fn(Wrap<T>) end up using different discriminators, then transmuting from one to the other would fail, no?

And same for pointer types themselves -- I don't know what the "discriminator" is there, but a *const bool should still be usable after being transmuted to *const u8.

[bjorn3]

Looks like we support the option to hash various things into the discriminator/salt beyond what the official arm64 ELF pauth ABI allows: https://github.com/rust-lang/rust/blob/a3e94c2ff51d6fa9929cf637fd85df3975119801/compiler/rustc_session/src/session.rs#L97-L107 If you did enable that, you did indeed get similar problems to CFI.

This code is wrong though: https://github.com/rust-lang/rust/blob/798151e197c3d53e57f070dc13878edf1ce4ece5/compiler/rustc_middle/src/ptrauth/discriminator.rs#L320-L331 That should be checking for optional references, not optional raw pointers. Optional raw pointers are not ABI compatible with raw pointers at all as raw pointers don't have a NULL niche. cc @jchlanda

[RalfJung]

It's also pretty concerning that apparently we need yet another copy of the same logic that computes the actual ABI of a type. And it'll likely be slightly different than all the other copies.

When do we stop accepting such code and insist on a proper refactor instead? (rust-lang/rust#119183)

[jchlanda]

Thank you for filling in the gaps @bjorn3.

Looks like we support the option to hash various things into the discriminator/salt beyond what the official arm64 ELF pauth ABI allows: https://github.com/rust-lang/rust/blob/a3e94c2ff51d6fa9929cf637fd85df3975119801/compiler/rustc_session/src/session.rs#L97-L107 If you did enable that, you did indeed get similar problems to CFI.

This code is wrong though: https://github.com/rust-lang/rust/blob/798151e197c3d53e57f070dc13878edf1ce4ece5/compiler/rustc_middle/src/ptrauth/discriminator.rs#L320-L331 That should be checking for optional references, not optional raw pointers. Optional raw pointers are not ABI compatible with raw pointers at all as raw pointers don't have a NULL niche. cc @jchlanda

Yes, you are right. I've addressed both Optoin<T> and the lack of support for repr(transparent) in the PR that contains the other half of this discussion.

There is a function in rustc that computes a "discriminator" for a function signature, and it takes into account the actual function type. IIUC, not just the key but also the discriminator has to be the same. If fn(T) and fn(Wrap) end up using different discriminators, then transmuting from one to the other would fail, no?

I'm not sure if you are worried about the second function using a transparent wrapper around T or a general transmute between different types case.
If it's the former, the bugfix mentioned above should address it (stripping of transparent wrappers).
If it's the latter, then there is a PR in the series that provides function pointer type discrimination support for transmutes. Assuming those two functions are extern "C" (as that is the only ABI that the support is provided for in the series of PRs) and the calculated discriminators do differ, the transmute would trigger a resign of the pointers:

  %0 = call i64 @llvm.ptrauth.resign(i64 ptrtoint (ptr ptrauth (ptr @_RNvCslF5CbeLcXhc_16transmute_simple7add_one, i32 0, i64 2981) to i64), i32 0, i64 2981, i32 0, i64 63165)
  %g = inttoptr i64 %0 to ptr
  %1 = call i32 %g(i32 10, i32 0) #6 [ "ptrauth"(i32 0, i64 63165) ]

In that example the pointer was transmuted from extern "C" fn(i32) -> i32 discriminator: 2981 to extern "C" fn(i32, i32) -> i32 discriminator: 63165.

And same for pointer types themselves -- I don't know what the "discriminator" is there, but a *const bool should still be usable after being transmuted to *const u8.

The discriminators are only calculated for (extern "C") function pointers.

[RalfJung]

Yes, you are right. I've addressed both Optoin and the lack of support for repr(transparent) in the rust-lang/rust#159074 that contains the other half of this discussion.

Okay, seems like I understood correctly then. Please have a look at our ABI compatibility rules. It must be the case that whenever types T and U are ABI-compatible, they have the same discriminator for function pointer authentication. Does your discriminator scheme ensure this?

If it's the latter, then there is a rust-lang/rust#159082 in the series that provides function pointer type discrimination support for transmutes. Assuming those two functions are extern "C" (as that is the only ABI that the support is provided for in the series of PRs) and the calculated discriminators do differ, the transmute would trigger a resign of the pointers:

That fix is incomplete, and IMO makes things worse. There are many ways to do a transmute in Rust, they must all be equivalent:

• You can call the transmute function
• You can store things in a union field of type T and then load from via a different field of type U
• You can store something via a raw pointer, cast the pointer, and load it at a different type.

I cannot think of any problem that you could fix by patching the transmute function.

Here is a function that code may use as a drop-in replacement for transmute whenever it wants:

pub unsafe fn my_transmute<T, U>(x: T) -> U {
    let x = std::mem::ManuallyDrop::new(x);
    unsafe { (&x as *const std::mem::ManuallyDrop<T>).cast::<U>().read() }
}

Your patch sounds like code would behave different when using my_transmute vs the built-in transmute. That would be a soundness bug, we cannot have that happen.

The discriminators are only calculated for (extern "C") function pointers.

So the pointer authentication scheme for data pointers does not use a discriminator / hard-codes it to 0?
That's one big chunk of potential problems less, good. :)