[PAC] Encoder and hash (1/8)

[jchlanda]

View all comments

This patch implements Rust's equivalent of Clang's function pointer type discriminator computation used for pointer authentication. Compatibility with Clang is a primary design goal. For a given extern "C" function type, the discriminator produced by Rust must match the value computed by Clang so that function pointers can be exchanged safely between Rust and C code while preserving pointer authentication semantics.

The implementation mirrors Clang's behavior in ASTContext::encodeTypeForFunctionPointerAuth, ensuring that identical C-compatible function types produce identical discriminators. See: https://clang.llvm.org/doxygen/ASTContext_8cpp.html#abb1375e068e807917527842d05cadea3.

---

This is part 1 of a sequence of 8 PRs that together implement support for function pointer type discrimination:

1. Encoder and hash
2. FnAbi, llvm.ptrauth.resign and Session API change
3. FPTR_TYPE_DISCR in ABI Version
4. Static allocs
5. Transmutes
6. Propagate discriminator logic through remaining get_fn_ptr calls sites
7. Minicore updates to support fn ptr type discriminator tests
8. Fn ptr type discrimination tests

---

Useful links:

• Previous PAC work:
  • pauthtest introduction: Introduce aarch64-unknown-linux-pauthtest target #155722
  • Library support follow up: Library support for aarch64-unknown-linux-pauthtest target #156548
  • Config follow up: Pointer authentication config and user facing options #156712
• Project goal and tracking issue
• Clang's implementation of ASTContext::encodeTypeForFunctionPointerAuth
• LLVM's SpiHash

[kovdan01]

Would it be possible to add unit tests for hash computation like the ones present in llvm source tree at llvm/unittests/Support/SipHashTest.cpp?

View changes since this review

[jchlanda]

Would it be possible to add unit tests for hash computation like the ones present in llvm source tree at llvm/unittests/Support/SipHashTest.cpp?

View changes since this review

Done in: 5e05159

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[davidtwco]

r? @davidtwco

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[jchlanda]

@rustbot ready

[scottmcm]

Are there licensing implications of this?

View changes since the review

[jchlanda]

I don't believe this introduces a licensing issue. LLVM appears to be using the reference vectors verbatim from the SipHash test vectors, which originate from: https://github.com/veorq/SipHash/blob/master/vectors.h

The tests here are just a trivial loop over those values to verify the implementation against the known reference outputs.

That said, I am not a lawyer and cannot provide any formal legal guarantee.

[davidtwco]

I think it should be okay to implement SipHash based on LLVM here, as that is permitted by LLVM's Apache-2.0 WITH LLVM-Exception license, but we should probably add a comment like this:

rust/compiler/rustc_llvm/llvm-wrapper/SymbolWrapper.cpp

Lines 1 to 8 in 0b63def

	// Derived from code in LLVM, which is:
	// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
	// See https://llvm.org/LICENSE.txt for license information.
	// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
	// Derived from:
	// * https://github.com/llvm/llvm-project/blob/ef6d1ec07c693352c4a60dd58db08d2d8558f6ea/llvm/include/llvm/Object/ArchiveWriter.h
	// * https://github.com/llvm/llvm-project/blob/ef6d1ec07c693352c4a60dd58db08d2d8558f6ea/llvm/lib/Object/ArchiveWriter.cpp

and a REUSE entry like this:

rust/REUSE.toml

Lines 58 to 65 in 0b63def

	[[annotations]]
	path = "compiler/rustc_llvm/llvm-wrapper/SymbolWrapper.cpp"
	precedence = "override"
	SPDX-FileCopyrightText = [
	"2003-2019 University of Illinois at Urbana-Champaign.",
	"The Rust Project Developers (see https://thanks.rust-lang.org)",
	]
	SPDX-License-Identifier = "Apache-2.0 WITH LLVM-exception AND (Apache-2.0 OR MIT)"

[jchlanda]

Done

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[davidtwco]

r=me after resolving #159071 (comment)

[jchlanda]

@rustbot ready