2015-03-10 03:04:35 +00:00
|
|
|
#![allow(dead_code)] // stack_guard isn't used right now on all platforms
|
|
|
|
|
2019-02-10 19:23:21 +00:00
|
|
|
use crate::cell::RefCell;
|
|
|
|
use crate::sys::thread::guard::Guard;
|
|
|
|
use crate::thread::Thread;
|
2014-12-07 08:32:50 +00:00
|
|
|
|
2014-11-25 16:52:10 +00:00
|
|
|
struct ThreadInfo {
|
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 #47863.
2018-01-31 19:41:29 +00:00
|
|
|
stack_guard: Option<Guard>,
|
2014-11-25 16:52:10 +00:00
|
|
|
thread: Thread,
|
|
|
|
}
|
|
|
|
|
2014-12-19 03:41:20 +00:00
|
|
|
thread_local! { static THREAD_INFO: RefCell<Option<ThreadInfo>> = RefCell::new(None) }
|
2014-11-25 16:52:10 +00:00
|
|
|
|
|
|
|
impl ThreadInfo {
|
2019-11-27 18:29:00 +00:00
|
|
|
fn with<R, F>(f: F) -> Option<R>
|
|
|
|
where
|
|
|
|
F: FnOnce(&mut ThreadInfo) -> R,
|
|
|
|
{
|
|
|
|
THREAD_INFO
|
|
|
|
.try_with(move |c| {
|
|
|
|
if c.borrow().is_none() {
|
|
|
|
*c.borrow_mut() =
|
|
|
|
Some(ThreadInfo { stack_guard: None, thread: Thread::new(None) })
|
|
|
|
}
|
|
|
|
f(c.borrow_mut().as_mut().unwrap())
|
|
|
|
})
|
|
|
|
.ok()
|
2014-11-25 16:52:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-15 19:27:05 +00:00
|
|
|
pub fn current_thread() -> Option<Thread> {
|
2014-11-25 16:52:10 +00:00
|
|
|
ThreadInfo::with(|info| info.thread.clone())
|
|
|
|
}
|
|
|
|
|
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 #47863.
2018-01-31 19:41:29 +00:00
|
|
|
pub fn stack_guard() -> Option<Guard> {
|
|
|
|
ThreadInfo::with(|info| info.stack_guard.clone()).and_then(|o| o)
|
2014-12-07 08:32:50 +00:00
|
|
|
}
|
|
|
|
|
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 #47863.
2018-01-31 19:41:29 +00:00
|
|
|
pub fn set(stack_guard: Option<Guard>, thread: Thread) {
|
2014-11-25 16:52:10 +00:00
|
|
|
THREAD_INFO.with(|c| assert!(c.borrow().is_none()));
|
2019-11-27 18:29:00 +00:00
|
|
|
THREAD_INFO.with(move |c| *c.borrow_mut() = Some(ThreadInfo { stack_guard, thread }));
|
2014-11-25 16:52:10 +00:00
|
|
|
}
|
2018-02-27 07:51:12 +00:00
|
|
|
|
|
|
|
pub fn reset_guard(stack_guard: Option<Guard>) {
|
|
|
|
THREAD_INFO.with(move |c| c.borrow_mut().as_mut().unwrap().stack_guard = stack_guard);
|
|
|
|
}
|