Summary: | x86-64: Support -mstack-protector-guard=global (define global __stack_chk_guard) | ||
---|---|---|---|
Product: | glibc | Reporter: | Fangrui Song <i> |
Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | carlos, drepper.fsp |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Fangrui Song
2020-10-30 03:22:58 UTC
Note, -mstack-protector-guard=tls can mitigate the problem by inserting a guard page between the stack and the static TLS block, but that can come with a large overhead. (In reply to Fangrui Song from comment #0) > (2) Security. > For a new thread, nptl/allocatestack.c allocates a memory region, places the > static TLS block at the end, and uses the remaining space as the thread > stack. > The stack pointer may be just a few hundred bytes below the canary address > (%fs:0x28 on x86-64) and a large out-of-bounds write can potentially > override it. We need to fix: Bug 11787 - Program with large TLS segments fail. https://sourceware.org/bugzilla/show_bug.cgi?id=11787 The static TLS should not be part of the stack accounting and when we split them out there won't be a problem with the stack being beside static TLS. |