diff options
author | Eric Sandeen <sandeen@sandeen.net> | 2008-04-22 16:38:23 -0500 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2008-05-26 16:15:33 +0200 |
commit | 7c9f8861e6c9c839f913e49b98c3854daca18f27 (patch) | |
tree | 220b23dff1aa11a83546fbc73a319575ca489188 /drivers/acpi/utilities/utresrc.c | |
parent | b40a4392a3c262e0d1b5379b4e142a8eefa63439 (diff) |
stackprotector: use canary at end of stack to indicate overruns at oops time
(Updated with a common max-stack-used checker that knows about
the canary, as suggested by Joe Perches)
Use a canary at the end of the stack to clearly indicate
at oops time whether the stack has ever overflowed.
This is a very simple implementation with a couple of
drawbacks:
1) a thread may legitimately use exactly up to the last
word on the stack
-- but the chances of doing this and then oopsing later seem slim
2) it's possible that the stack usage isn't dense enough
that the canary location could get skipped over
-- but the worst that happens is that we don't flag the overrun
-- though this happens fairly often in my testing :(
With the code in place, an intentionally-bloated stack oops might
do:
BUG: unable to handle kernel paging request at ffff8103f84cc680
IP: [<ffffffff810253df>] update_curr+0x9a/0xa8
PGD 8063 PUD 0
Thread overran stack or stack corrupted
Oops: 0000 [1] SMP
CPU 0
...
... unless the stack overrun is so bad that it corrupts some other
thread.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'drivers/acpi/utilities/utresrc.c')
0 files changed, 0 insertions, 0 deletions