Bring arm64e/ptrauth support to parity with main upstreaming branch #8946
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Try to optimize a call to the result of a ptrauth intrinsic, potentially into the ptrauth call bundle: - call(ptrauth.resign(p)), ["ptrauth"()] -> call p, ["ptrauth"()] - call(ptrauth.sign(p)), ["ptrauth"()] -> call p - call(ptrauth.auth(p)) -> call p, ["ptrauth"()] as long as the key/discriminator are the same in sign and auth-bundle. This relaxes the existing combine in one major way: it can generate calls with ptrauth bundles with a different key from the existing call. Without knowledge of the target keys, this may be unsound. Generating a plain call to a raw unauthenticated pointer is generally undesirable, but if we ended up seeing a naked ptrauth.sign in the first place, we already have suspicious code. Unauthenticated calls are also easier to spot than naked signs, so let the indirect call shine.
Try to optimize a call to a ptrauth constant, into its ptrauth bundle: call(ptrauth(f)), ["ptrauth"()] -> call f as long as the key/discriminator are the same in constant and bundle.
This introduces 3 hardening modes in the authentication step of auth/resign lowering: - unchecked, which uses the AUT instructions as-is - poison, which detects authentication failure (using an XPAC+CMP sequence), explicitly yielding the XPAC result rather than the AUT result, to avoid leaking - trap, which additionally traps on authentication failure, using BRK #0xC470 + key (IA C470, IB C471, DA C472, DB C473.) Not all modes are necessarily useful in all contexts, and there are more performant alternative lowerings in specific contexts (e.g., when I/D TBI enablement is a target ABI guarantee.) This is controlled by the `ptrauth-auth-traps` function attributes, and can be overridden using `-aarch64-ptrauth-auth-checks=`.
When the FPAC feature is present, we can rely on its faulting behavior to avoid emitting the expensive authentication failure check sequence ourvelves. In which case we emit the same sequence as a plain unchecked auth/resign.
This removes x16/x17 from tcGPR64, to use them for the check sequence. That further triggers a change in synthesized regclasses, and both that and tcGPR64 in turn cause various regalloc changes.
Used for lowering some code refs to ptrauth constants.
This was the last one of the ExpandHardenedPseudos, as it's now done in AsmPrinter. The original LOH use-case can now be replaced with late LOH emission from within AsmPrinter itself.
This includes a new pseudo-instruction, XPACIuntied, to be used when lowering @llvm.returnaddress: it avoids clobbering LR, thereby saving a stack frame when it's not otherwise needed.
Give users an option to sign a function pointer using a non-zero discrimiantor based on the type of the destination. Co-authored-by: John McCall <[email protected]>
With signed null, signed uintptr and isa pointer support.
__cxa_throw is declared to take its destructor as void (*)(void *). We must match that if function pointers can be authenticated with a discriminator based on their type.
Enabled in clang using:
-fptrauth-indirect-gotos
and at the IR level using function attribute:
"ptrauth-indirect-gotos"
Signing uses IA and a per-function integer discriminator.
The discriminator isn't ABI-visible, and is currently:
ptrauth_string_discriminator("<function_name> blockaddress")
A sufficiently sophisticated frontend could benefit from
per-indirectbr discrimination, which would need additional
machinery, such as allowing "ptrauth" bundles on indirectbr.
For our purposes, the simple scheme above is sufficient.
I couldn't find users after all, including in lldb.
ahmedbougacha
force-pushed
the
arm64e-upstream-next
branch
from
3c0e47b
to
878d4f7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.