This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/81708] New: The x86 stack canary location should be customizable
- From: "luto at kernel dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 04 Aug 2017 00:31:46 +0000
- Subject: [Bug target/81708] New: The x86 stack canary location should be customizable
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
Bug ID: 81708
Summary: The x86 stack canary location should be customizable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at kernel dot org
Target Milestone: ---
There are four credible ways to find the stack canary:
1. %fs:symbol
2. %fs:symbol(%rip) [with a PCREL relocation]
3. %gs:symbol
4. %gs:symbol(%rip)
(Obviously the %rip variants only work on x86_64.)
The current code is roughly equivalent to (1) or (3) where symbol is an
absolute symbol equal to 0x28 or similar.
Please give a command line option to choose any of the four modes and specify
the symbol name. (Or just hardcode the symbol name to __gcc_stack_canary or
whatever if the option is set.)
My perferred solution would be -mstack-protector-cookie=gs:symname or
-mstack-protector-cookie=gs:symname(%rip) or -mstack-protector-cookie=gs:0x28
depending on what's desired.
I personally consider it to have been a mistake for Linux to support a stack
canary without insisting that GCC fix this issue first. The x86_32 case, in
particular, is a collossal mess in the kernel that slows kernel entries down
and seriously overcomplicates the kernel code because the stack canary
addressing mode that GCC chooses is nonsensical.