Skip to content

fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia - #159873

Open
PiJoules wants to merge 3 commits into
rust-lang:mainfrom
PiJoules:fuchsia-safestack
Open

fuchsia: Add safestack as a supported sanitizer for x86_64 fuchsia#159873
PiJoules wants to merge 3 commits into
rust-lang:mainfrom
PiJoules:fuchsia-safestack

Conversation

@PiJoules

Copy link
Copy Markdown
Contributor

Make it also enabled by default just like it is for clang.

@rustbot

rustbot commented Jul 24, 2026

Copy link
Copy Markdown
Collaborator

These commits modify compiler targets.
(See the Target Tier Policy.)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 24, 2026
@rustbot

rustbot commented Jul 24, 2026

Copy link
Copy Markdown
Collaborator

r? @adwinwhite

rustbot has assigned @adwinwhite.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 74 candidates
  • Random selection from 18 candidates

@PiJoules

Copy link
Copy Markdown
Contributor Author

r? @erickt

@rustbot

rustbot commented Jul 24, 2026

Copy link
Copy Markdown
Collaborator

Failed to set assignee to erickt: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

@rust-log-analyzer

This comment has been minimized.

@workingjubilee

Copy link
Copy Markdown
Member

huh. that's weird.

@adwinwhite

Copy link
Copy Markdown
Contributor

@rustbot author

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 13, 2026
@rustbot

rustbot commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

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

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 13, 2026
Make it also enabled by default just like it is for clang.
tests/assembly-llvm/stack-protector/stack-protector-target-support.rs.
Since safestack is enabled by default for fuchsia, it will not emit
__stack_chk_fail calls.
@rustbot

rustbot commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

These commits modify compiler targets.
(See the Target Tier Policy.)

@rustbot

rustbot commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

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.

@PiJoules

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 26, 2026

@adwinwhite adwinwhite Aug 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

So __stack_chk_fail is optimized away if we have safe stack on?

Rather than remove testing for stack protector support, would it be better to mark the function with #[sanitize(safestack = "off")]?

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

So __stack_chk_fail is optimized away if we have safe stack on?

Specifically it's never emitted since the safestack machinery would move all stack references to the unsafe stack so the current safe stack wouldn't need the normal stack protector instrumentation.

Rather than remove testing for stack protector support, would it be better to mark the function with #[sanitize(safestack = "off")]?

Yeah I think that also works

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Apparently safestack wasn't a valid option for that macro, but #161888 should make it one

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could you also add a comment on the sanitize attribute that we only do this because we can't disable default sanitizers via compile-flags?

@adwinwhite adwinwhite added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2026
jhpratt added a commit to jhpratt/rust that referenced this pull request Aug 29, 2026
…ble, r=adwinwhite

compiler: Allow safestack to be togglable via #[sanitize(safestack = "...")]

Since safestack is a sanitizer, it should be possible to allow enabling/disabling it on functions like we do with the other sanitizers. It's likely that when adding the `#[sanitize(...)]` support for the other ones that safestack was just missed, so this makes safestack follow suite. It was also suggested in rust-lang#159873 that we just disable safestack this way for a specific test where we should check stack protector instrumentation.
rust-bors Bot pushed a commit that referenced this pull request Aug 29, 2026
Rollup merge of #161888 - PiJoules:sanitize-safestack-togglable, r=adwinwhite

compiler: Allow safestack to be togglable via #[sanitize(safestack = "...")]

Since safestack is a sanitizer, it should be possible to allow enabling/disabling it on functions like we do with the other sanitizers. It's likely that when adding the `#[sanitize(...)]` support for the other ones that safestack was just missed, so this makes safestack follow suite. It was also suggested in #159873 that we just disable safestack this way for a specific test where we should check stack protector instrumentation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants