This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/81708] New: The x86 stack canary location should be customizable


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]