Skip to content

Add support for aarch64-unknown-linux-pauthtest #755

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
jchlanda wants to merge 2 commits into
base: master
Choose a base branch
from
+33 −1
Draft

Add support for aarch64-unknown-linux-pauthtest #755

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e6cc54b
Add support for `aarch64-unknown-linux-pauthtest`
jchlanda Apr 20, 2026
67a02e0
Reword the note
jchlanda Apr 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions src/backtrace/libunwind.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,18 @@ impl Frame {
// clause, and if this is fixed that test in theory can be run on macOS!
if cfg!(target_vendor = "apple") {
self.ip()
} else if cfg!(target_env = "pauthtest") {
Copy link
Copy Markdown
Member

@bjorn3 bjorn3 Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this not check for the respective target feature being enabled? Not every target with pointer authentication enabled will use that target env, right?

Copy link
Copy Markdown
Author

@jchlanda jchlanda Apr 23, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right.
We're in the middle of preparing an upstream patch that introduces a pointer authentication aware target. It just so happens that in there I ended up using (incorrectly) the target environment as the gating mechanism.

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.

This will become a bit more clear once the PR lands and I submit a ticket.

// NOTE: As ip here is not signed (raw, non-PAC-enabled pointer) we
// must not use uw::_Unwind_FindEnclosingFunction. This is because,
// for pauthtest toolchain, libunwind will try to authenticate and
// resign it. Signing here (apart from risking creating a signing
// oracle) is not possible. According to the schema the value must
// be signed using SP as the discriminator - which is the problem.
// SP obtained here would not match the SP at the auth-resign time,
// as uw::_Unwind_FindEnclosingFunction creates a new context so
// the SP used for signing here would belong to a different frame
// that the one used for auth-resign. Hence return a raw value.
self.ip()
Copy link
Copy Markdown
Member

@bjorn3 bjorn3 Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is ip not signed? It is directly the result of _Unwind_GetIP. It should be possible to pass that to _Unwind_FindEnclosingFunction. How else would you even be able to use _Unwind_FindEnclosingFunction otherwise?

Copy link
Copy Markdown
Author

@jchlanda jchlanda Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is ip not signed? It is directly the result of _Unwind_GetIP.

A raw ip is expected. _Unwind_GetIP authenticates the pointer and returns a stripped version (via ptrauth_auth_data here).

It should be possible to pass that to _Unwind_FindEnclosingFunction. How
else would you even be able to use _Unwind_FindEnclosingFunction otherwise?

This is the crux of the issue. _Unwind_FindEnclosingFunction is fundamentally incompatible with the pointer authentication model. The problem is that _Unwind_FindEnclosingFunction does not follow PAC semantics, it blindly creates a fresh unwind cursor and then resets the instruction pointer here: __unw_set_reg(cursor, UNW_REG_IP, pc);. As if to say: "treat this pc as if it belonged to this new cursor's frame".

__unw_set_reg does apply PAC logic internally (authenticates) under the assumption that the ip behaves like a return address for the current frame.

This cannot be fixed on the Rust side. _Unwind_FindEnclosingFunction constructs a new cursor (and therefore a new sp), so there is no way to correctly sign pointer: any signing we would perform would use the wrong context and would still fail authentication inside libunwind.

Copy link
Copy Markdown
Member

@bjorn3 bjorn3 Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a bug in libunwind to me. What purpose does _Unwind_FindEnclosingFunction have at all if you can't pass the result of _Unwind_GetIP to it?

Copy link
Copy Markdown
Author

@jchlanda jchlanda Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure, the documentation seems to be pretty scarce, and one I found is rather quite lax about possible outcomes of the call, explicitly allowing failure.

I personally don't read it as a bug. To me it is more that _Unwind_FindEnclosingFunction was designed before pointer authentication existed, and its API implicitly assumes that instruction pointers are context-free values. But in PAC-aware code PC is only meaningful in the context of the (original) SP.

Copy link
Copy Markdown
Member

@bjorn3 bjorn3 Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does _Unwind_FindEnclosingFunction need an authenticated pointer? It doesn't dereference the pointer, only looks it up in a side table with the result not having any security relevance. The only useful thing you can do with it afaik is looking up debuginfo for the function. Due to inlining and outlining you can't guarantee that it points to any particular function.

Copy link
Copy Markdown
Author

@jchlanda jchlanda Apr 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me re-phrase the problem here.

Why does _Unwind_FindEnclosingFunction need an authenticated pointer?

It does not, perhaps this was an oversimplification on my side. The real problem is about what invariant __unw_set_reg is enforcing under PAC - and since _Unwind_FindEnclosingFunction calls set reg, that's why the simplification crept into the discussion.

You are right that _Unwind_GetIP returns a usable pointer. It authenticates a signed pointer with the original sp and gives you a stripped version.
The problem shows up in _Unwind_FindEnclosingFunction, because it creates a fresh cursor (ergo a new sp) and then calls:

__unw_set_reg(&cursor, UNW_REG_IP, pc);

On PAC aware platforms this will go through an auth/resign sequence:

        unw_word_t opaque_value = (uint64_t)ptrauth_auth_and_resign(
            (void *)value, ptrauth_key_return_address, sp,
            ptrauth_key_return_address, &authenticated_value);

What that code does is it enforces that value (ip from Rust) is a valid for this cursor's sp - so ip must be a return address for the current frame.

However, as you noted: ip is stripped by _Unwind_GetIP and there is no way for us to sign it. So there is no way to make it pass auth/resign check. We can’t re-sign it correctly because we don’t have the original sp, and using the new sp will fail authentication.

So the issue isn’t just "signed vs unsigned". It’s that _Unwind_FindEnclosingFunction relies on being able to treat a pointer as if it were a return address for an arbitrary frame, while __unw_set_reg (correctly) enforces that return addresses are sp-bound under PAC. And that is what makes _Unwind_FindEnclosingFunction fundamentally incompatible.

As a side note a notion of lack of support for symbol_address is already present in the test suite.

} else {
unsafe { uw::_Unwind_FindEnclosingFunction(self.ip()) }
}
Expand Down
6 changes: 6 additions & 0 deletions tests/skip_inner_frames.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,12 @@ const ENABLED: bool = cfg!(all(
target_os = "linux",
// On ARM finding the enclosing function is simply returning the ip itself.
not(target_arch = "arm"),
// On `aarch64-unknown-linux-pauthtest` `_Unwind_FindEnclosingFunction`
// cannot be used safely, because instruction pointers are not in a form
// suitable for authentication/resigning, so `symbol_address()` returns the
// raw IP instead. In this case the returned address may be inside the
// function body rather than at its entry.
not(target_env = "pauthtest"),
));

#[test]
Expand Down
12 changes: 11 additions & 1 deletion tests/smoke.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,13 @@ fn get_actual_fn_pointer(fp: *mut c_void) -> *mut c_void {
}

#[test]
// This test relies on recovering precise symbol addresses from instruction
// pointers. On `aarch64-unknown-linux-pauthtest`, we cannot safely use
// `_Unwind_FindEnclosingFunction`, and instead fall back to using raw
// instruction pointers. As a result, symbol resolution cannot reliably
// recover a canonical function entry address, and `sym.addr()` will often be
// `None`. Therefore this test is disabled.
#[cfg_attr(target_env = "pauthtest", ignore)]
// FIXME: shouldn't ignore this test on i686-msvc, unsure why it's failing
#[cfg_attr(all(target_arch = "x86", target_env = "msvc"), ignore)]
#[inline(never)]
Expand Down Expand Up @@ -310,7 +317,10 @@ fn sp_smoke_test() {
let r = refs.pop().unwrap();
eprintln!("ref = {:p}", r);
if sp as usize != 0 {
assert!(r > sp);
// Stack grows down, however stack slots can be reused and
// frame pointers ommited, `r == sp` should be a valid edge
// case.
assert!(r >= sp);
if let Some(child_ref) = child_ref {
assert!(sp >= child_ref);
}
Expand Down
Loading