Skip the main thread's manual stack guard on Linux #43072
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
|
@bors: r+ Nice patch! Also yeah the kernel compatibility here sounds good to me, thanks for looking into that! |
|
📌 Commit deac996 has been approved by |
|
🔒 Merge conflict |
alexcrichton
added
the
S-waiting-on-author
Linux doesn't allocate the whole stack right away, and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard, then the kernel starts enforcing a rather large gap above that, rendering much of the possible stack space useless. Instead, we'll just note where we expect rlimit to start faulting, so our handler can report "stack overflow", and trust that the kernel's own stack guard will work. Fixes rust-lang#43052.
cuviper
force-pushed
the
linux-stack-guard
branch
from
deac996
to
be509b3
Compare
|
Silly @bors. Rebased. |
|
@bors: r+ |
|
📌 Commit be509b3 has been approved by |
bors
added a commit
that referenced
this pull request
Jul 8, 2017
Skip the main thread's manual stack guard on Linux Linux doesn't allocate the whole stack right away, and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard, then the kernel starts enforcing a rather large gap above that, rendering much of the possible stack space useless. Instead, we'll just note where we expect rlimit to start faulting, so our handler can report "stack overflow", and trust that the kernel's own stack guard will work. Fixes #43052. r? @alexcrichton ### Kernel compatibility: Strictly speaking, Rust claims support for Linux kernels >= 2.6.18, and stack guards were only added to mainline in 2.6.36 for [CVE-2010-2240]. But since that vulnerability was so severe, the guards were backported to many stable branches, and Red Hat patched this all the way back to RHEL3's 2.4.21! I think it's reasonable for us to assume that any *supportable* kernel should have these stack guards. At that time, the kernel only enforced one page of padding between the stack and other mappings, but thanks to [Stack Clash] that padding is now much larger, causing #43052. The kernel side of those fixes are in [CVE-2017-1000364], which Red Hat has backported to at least RHEL5's 2.6.18 so far. [CVE-2010-2240]: https://access.redhat.com/security/cve/CVE-2010-2240 [CVE-2017-1000364]: https://access.redhat.com/security/cve/CVE-2017-1000364 [Stack Clash]: https://access.redhat.com/security/vulnerabilities/stackguard
|
☀️ Test successful - status-appveyor, status-travis |
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.
Linux doesn't allocate the whole stack right away, and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard, then the kernel starts enforcing a rather large gap above that, rendering much of the possible stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so our handler can report "stack overflow", and trust that the kernel's own stack guard will work.
Fixes #43052.
r? @alexcrichton
Kernel compatibility:
Strictly speaking, Rust claims support for Linux kernels >= 2.6.18, and stack guards were only added to mainline in 2.6.36 for CVE-2010-2240. But since that vulnerability was so severe, the guards were backported to many stable branches, and Red Hat patched this all the way back to RHEL3's 2.4.21! I think it's reasonable for us to assume that any supportable kernel should have these stack guards.
At that time, the kernel only enforced one page of padding between the stack and other mappings, but thanks to Stack Clash that padding is now much larger, causing #43052. The kernel side of those fixes are in CVE-2017-1000364, which Red Hat has backported to at least RHEL5's 2.6.18 so far.