Skip to content
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.

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

Skip the main thread's manual stack guard on Linux #43072

Merged
merged 1 commit into from Jul 8, 2017

Conversation

Projects
None yet
3 participants
@cuviper
Copy link
Member

commented Jul 5, 2017

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.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jul 5, 2017

@bors: r+

Nice patch! Also yeah the kernel compatibility here sounds good to me, thanks for looking into that!

@bors

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2017

📌 Commit deac996 has been approved by alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2017

🔒 Merge conflict

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.

@cuviper cuviper force-pushed the cuviper:linux-stack-guard branch from deac996 to be509b3 Jul 7, 2017

@cuviper

This comment has been minimized.

Copy link
Member Author

commented Jul 7, 2017

Silly @bors. Rebased.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Jul 7, 2017

@bors: r+

@bors

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2017

📌 Commit be509b3 has been approved by alexcrichton

@bors

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2017

⌛️ Testing commit be509b3 with merge 4b6af97...

bors added a commit that referenced this pull request Jul 8, 2017

Auto merge of #43072 - cuviper:linux-stack-guard, r=alexcrichton
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
@bors

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 4b6af97 to master...

@bors bors merged commit be509b3 into rust-lang:master Jul 8, 2017

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@cuviper cuviper deleted the cuviper:linux-stack-guard branch Sep 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.