Skip to content

Auth handler and restorer#8

Merged
atrosinenko merged 4 commits into
access-softek:v1.2.5-pauth-rev2025-11-21from
jchlanda:jakub/handler_restorer_auth
Apr 28, 2026
Merged

Auth handler and restorer#8
atrosinenko merged 4 commits into
access-softek:v1.2.5-pauth-rev2025-11-21from
jchlanda:jakub/handler_restorer_auth

Conversation

@jchlanda
Copy link
Copy Markdown

@jchlanda jchlanda commented Apr 8, 2026

Previously restorer was only stripped, while handler was left untouched. Without authenticating kernel would receive a signed address and use it, as is, to call the signal handler, which would result in an invalid memory access.

@jchlanda
Copy link
Copy Markdown
Author

jchlanda commented Apr 8, 2026

@kovdan01

Copy link
Copy Markdown

@kovdan01 kovdan01 left a comment

Choose a reason for hiding this comment

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

Thanks @jchlanda! Do I get it right that this was already tested with rust? If so, LGTM

Comment thread src/signal/sigaction.c Outdated
Previously restorer was only stripped, while handler was left untouched.
Without authenticating kernel would receive a signed address and use it,
as is, to call the signal handler, which would result in an invalid
memory access.
@jchlanda jchlanda force-pushed the jakub/handler_restorer_auth branch from ece31aa to 5ef373a Compare April 8, 2026 11:40
@jchlanda
Copy link
Copy Markdown
Author

jchlanda commented Apr 8, 2026

Thanks @jchlanda! Do I get it right that this was already tested with rust? If so, LGTM

Yeap, https://github.com/rust-lang/rust/blob/main/tests/ui/abi/stack-probes.rs#L1 - the original failing test that uncovered this for us - is passing with this patch.

@atrosinenko
Copy link
Copy Markdown

@kovdan01 I wonder if we have to account for -fptrauth-function-pointer-type-discrimination here?

@kovdan01
Copy link
Copy Markdown

kovdan01 commented Apr 8, 2026

@kovdan01 I wonder if we have to account for -fptrauth-function-pointer-type-discrimination here?

We do, but our current musl implementation does not support it anyway (there are other similar places). So trying to account for it here would be pretending that we support that everywhere, while this is simply not true. I'll file an issue on this.

@jchlanda Could you please add a has_feature check against fn type discr, and if it's present, just fall to a preprocessor error?

@kovdan01
Copy link
Copy Markdown

kovdan01 commented Apr 8, 2026

I'll file an issue on this.

See #9

@kovdan01
Copy link
Copy Markdown

kovdan01 commented Apr 8, 2026

Yeap, https://github.com/rust-lang/rust/blob/main/tests/ui/abi/stack-probes.rs#L1 - the original failing test that uncovered this for us - is passing with this patch.

@jchlanda Thanks! Just double-checking: the remaining tests are also passing, right? :) I mean, when experimenting with this yesterday and when switching from strip to auth, I had many other new failures. These are probably guarded now with your checks against SIG_DFL and SIG_IGN. So, does this mean that everything else is also passing?

@jchlanda
Copy link
Copy Markdown
Author

jchlanda commented Apr 8, 2026

Yeap, https://github.com/rust-lang/rust/blob/main/tests/ui/abi/stack-probes.rs#L1 - the original failing test that uncovered this for us - is passing with this patch.

@jchlanda Thanks! Just double-checking: the remaining tests are also passing, right? :) I mean, when experimenting with this yesterday and when switching from strip to auth, I had many other new failures. These are probably guarded now with your checks against SIG_DFL and SIG_IGN. So, does this mean that everything else is also passing?

Yeap, that would be my guess, trying to auth those two will obviously fail. All the rust tests are passing with this patch.

@jchlanda Could you please add a has_feature check against fn type discr, and if it's present, just fall to a preprocessor error?

Aye, done.

@jchlanda jchlanda requested a review from kovdan01 April 8, 2026 12:32
Copy link
Copy Markdown

@atrosinenko atrosinenko left a comment

Choose a reason for hiding this comment

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

Looks like this patch unintentionally "rendered" TABs as 8 spaces (accidentally spotted this as my Github interface preference is set to 4 spaces), though I'm not sure we care about this here.

Comment thread src/signal/sigaction.c Outdated
Comment thread src/signal/sigaction.c Outdated
@jchlanda
Copy link
Copy Markdown
Author

jchlanda commented Apr 9, 2026

Looks like this patch unintentionally "rendered" TABs as 8 spaces (accidentally spotted this as my Github interface preference is set to 4 spaces), though I'm not sure we care about this here.

@atrosinenko apologies, that’s from my clang-format. I can't see a formatting config in the repo; how do you usually handle code style here?

@atrosinenko
Copy link
Copy Markdown

I can't see a formatting config in the repo; how do you usually handle code style here?

I use this repo in a read-only manner most of the time :) Maybe @kovdan01 has something to suggest, but I guess we don't care for code style here as much as in the LLVM repo (where code style was semi-automatically enforced for a long time and thus it is much easier for the new patches to adhere to the rules). I'm not sure, maybe there is something similar in Musl upstream, but I'm not sure we are contributing there actively. To my understanding, this fork of Musl is kind of proof-of-concept for testing, @kovdan01 please correct me if I'm wrong.

@jchlanda
Copy link
Copy Markdown
Author

I can't see a formatting config in the repo; how do you usually handle code style here?

I use this repo in a read-only manner most of the time :) Maybe @kovdan01 has something to suggest, but I guess we don't care for code style here as much as in the LLVM repo (where code style was semi-automatically enforced for a long time and thus it is much easier for the new patches to adhere to the rules). I'm not sure, maybe there is something similar in Musl upstream, but I'm not sure we are contributing there actively. To my understanding, this fork of Musl is kind of proof-of-concept for testing, @kovdan01 please correct me if I'm wrong.

I've done something similar-looking to what we already have in the files. Also tabs, instead of spaces.

@jchlanda jchlanda requested a review from atrosinenko April 20, 2026 08:10
Comment thread src/signal/sigaction.c
Copy link
Copy Markdown

@atrosinenko atrosinenko left a comment

Choose a reason for hiding this comment

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

Looks good, thank you!

@atrosinenko
Copy link
Copy Markdown

@jchlanda Oh, I forgot to say that you can ask me to merge this PR on your behalf if no more changes are planned and no reviews are waited for :)

@jchlanda
Copy link
Copy Markdown
Author

@jchlanda Oh, I forgot to say that you can ask me to merge this PR on your behalf if no more changes are planned and no reviews are waited for :)

That would be great, thank you.

@atrosinenko atrosinenko merged commit a88d427 into access-softek:v1.2.5-pauth-rev2025-11-21 Apr 28, 2026
@atrosinenko
Copy link
Copy Markdown

FYI In https://github.com/access-softek/pauth-toolchain-build-scripts the particular hashes of llvm-project and musl are hard-coded in ./config, meaning if you rely on these scripts, you have to either change the version locally or commit that update (maybe after landing other patches to musl if more are planned).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants