Use a range to identify SIGSEGV in stack guards #47912
Merged
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
Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
|
r? @KodrAus (rust_highfive has picked a reviewer for you, use r? to override) |
|
The nature of this change meant I had to change platforms that I have no means to test. I believe I have preserved the semantics of non-linux-gnu targets, but please do apply extra scrutiny. I especially thought that freebsd looked weird, for which I left a FIXME comment. |
kennytm
added
the
S-waiting-on-review
|
📌 Commit 55b54a9 has been approved by |
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Feb 3, 2018
…ichton Use a range to identify SIGSEGV in stack guards Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
bors
added a commit
that referenced
this pull request
Feb 3, 2018
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Feb 4, 2018
…ichton Use a range to identify SIGSEGV in stack guards Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Feb 4, 2018
…ichton Use a range to identify SIGSEGV in stack guards Previously, the `guard::init()` and `guard::current()` functions were returning a `usize` address representing the top of the stack guard, respectively for the main thread and for spawned threads. The `SIGSEGV` handler on `unix` targets checked if a fault was within one page below that address, if so reporting it as a stack overflow. Now `unix` targets report a `Range<usize>` representing the guard memory, so it can cover arbitrary guard sizes. Non-`unix` targets which always return `None` for guards now do so with `Option<!>`, so they don't pay any overhead. For `linux-gnu` in particular, the previous guard upper-bound was `stackaddr + guardsize`, as the protected memory was *inside* the stack. This was a glibc bug, and starting from 2.27 they are moving the guard *past* the end of the stack. However, there's no simple way for us to know where the guard page actually lies, so now we declare it as the whole range of `stackaddr ± guardsize`, and any fault therein will be called a stack overflow. This fixes rust-lang#47863.
|
Is there a recommended way to backport this to |
|
You can borrow the patches from Fedora: |
|
Thanks! |
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.
Previously, the
guard::init()andguard::current()functions werereturning a
usizeaddress representing the top of the stack guard,respectively for the main thread and for spawned threads. The
SIGSEGVhandler on
unixtargets checked if a fault was within one page below thataddress, if so reporting it as a stack overflow.
Now
unixtargets report aRange<usize>representing the guard memory,so it can cover arbitrary guard sizes. Non-
unixtargets which alwaysreturn
Nonefor guards now do so withOption<!>, so they don't pay anyoverhead.
For
linux-gnuin particular, the previous guard upper-bound wasstackaddr + guardsize, as the protected memory was inside the stack.This was a glibc bug, and starting from 2.27 they are moving the guard
past the end of the stack. However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of
stackaddr ± guardsize, and any fault therein will be called a stackoverflow. This fixes #47863.