Add support for aarch64-unknown-linux-pauthtest target

[jchlanda]

Description

This PR adds support for aarch64-unknown-linux-pauthtest, a target that
enables Pointer Authentication Code (PAC) support in Rust on AArch64 ELF based
Linux systems using a pauthtest ABI (provided by LLVM) and pauthtest-enabled
sysroot with custom musl, serving as a reference libc implementation.

Please consult a rust-lang PR for the details on the target: rust-lang/rust#155722

Sources

This target reuses the existing musl implementation paths in libc and does not
introduce new platform-specific APIs. aarch64-unknown-linux-pauthtest should
be treated as musl-compatible.

Checklist

• Relevant tests in libc-test/semver have been updated - N/A (no semver-affecting API changes)
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);

@rustbot label +stable-nominated

[tgross35]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

[jchlanda]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

I knew about the need for patches to libc and cc. Did not realise about the no-std first. Do you mean that the target should first have TargetMetadata.std set to false?

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

The API surface should be identical. However they are most definitely not interchangeable.
This will be more clear once the rust-lang PR lands, but in there I've used aarch64-unknown-linux-pauthtest, and (somewhat incorrectly) gated the code on the environment part of the triple. We have a follow up task to resolve the target to a set of features, just like it's done in clang where it solves platform/environment specifics on the driver level and later on everything is based on language flags that are there regardless of the platform. And finally are resolved to a concrete signing schema.

Another deviation is that for the new target statically linked libc is not an option, so perhaps it would be good to keep the distinction clear also at the cfg checks?

[tgross35]

Rust PR for reference https://github.com/rust-lang/rust/pulls/jchlanda

[tgross35]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

I new about the need for patches to libc and cc. Did not realise about the no-std first. Do you mean that the target should first have TargetMetadata.std set to false?

Yes, but I think that flag only controls -Zbuild-std. Beyond that, the initial r-l/r PR shouldn't touch library/std - after rustc is capable of building something for the target, it's a lot easier to bring std up incrementally. Also the initial merge of compiler support serves as an indicator to the ecosystem that the target is official, so dependencies of std know they can start accepting support patches (e.g. this crate).

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

The API surface should be identical. However they are most definitely not interchangeable. This will be more clear once the rust-lang PR lands, but in there I've used aarch64-unknown-linux-pauthtest, and (somewhat incorrectly) gated the code on the environment part of the triple. We have a follow up task to resolve the target to a set of features, just like it's done in clang where it solves platform/environment specifics on the driver level and later on everything is based on language flags that are there regardless of the platform. And finally are resolved to a concrete signing schema.

I don't know the exact details about pauthtest but I still think what I described sounds like a reasonable enough fit. If it looks like musl for ~95% of the API then it's going to be easiest to call it target_env = "musl" since target_env mostly serves as the library config. In the more rare cases that you need to know the difference, checking target_abi = "pauthtest" will work. "Same env, different ABI" also sounds like the right intuition here from my (limited) understanding.

But that's just my thoughts, the others may feel differently. Probably worth a Zulip discussion at some point.

Another deviation is that for the new target statically linked libc is not an option, so perhaps it would be good to keep the distinction clear also at the cfg checks?

You'd still be able to cfg(target_abi = "pauthtest") where needed. And targets that support both can usually toggle +crt-static/-crt-static so code that needs to know about linkage has to be able to support both to some extent.

On that note, are there other libcs that could work for pauthtest eventually aside from the musl fork?