public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Maxim Blinov <maxim.blinov@embecosm.com>
To: gdb@sourceware.org
Subject: use of %fs segment register in x86_64 with -fstack-check
Date: Tue, 03 Mar 2020 14:53:00 -0000	[thread overview]
Message-ID: <CADmoyEiiCOqjvkydY+OQUN+hVBKidLXDc7A4o+fZgRj3meUAYw@mail.gmail.com> (raw)

Hi all,

I'm looking at some -fstack-check'ed code, and would appreciate it if
some gdb x86_64 gurus could double check my understanding of a trivial
example

here is the source:

big-access.c:
```
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

extern void foo(char *);

int main()
{
  char ch[8000];
  foo (ch);

  return 0;
}
```

foo.c:
```
void foo(char *ch) { }
```

And the compilation line:

$ gcc -O2 -fstack-check -o big-access big-access.c foo.c -fdump-rtl-final

And here is the gdb view (ignore the breakpoint and current insn caret):
```
B+ │0x555555554560 <main>           sub    $0x2f78,%rsp
   │0x555555554567 <main+7>         orq    $0x0,0xf58(%rsp)
   │0x555555554570 <main+16>        orq    $0x0,(%rsp)
   │0x555555554575 <main+21>        add    $0x1020,%rsp
   │0x55555555457c <main+28>        mov    %rsp,%rdi
   │0x55555555457f <main+31>        mov    %fs:0x28,%rax
  >│0x555555554588 <main+40>        mov    %rax,0x1f48(%rsp)
   │0x555555554590 <main+48>        xor    %eax,%eax
   │0x555555554592 <main+50>        callq  0x5555555546d0 <foo>
   │0x555555554597 <main+55>        mov    0x1f48(%rsp),%rdx
   │0x55555555459f <main+63>        xor    %fs:0x28,%rdx
   │0x5555555545a8 <main+72>        jne    0x5555555545b4 <main+84>
   │0x5555555545aa <main+74>        xor    %eax,%eax
   │0x5555555545ac <main+76>        add    $0x1f58,%rsp
   │0x5555555545b3 <main+83>        retq
   │0x5555555545b4 <main+84>        callq  0x555555554540 <__stack_chk_fail@plt>
   │0x5555555545b9                  nopl   0x0(%rax)
```

I would just like someone who knows their stuff to double check my
understanding:

The "orq" at the start are purposefully causing a "dummy" load/store
event so the VMM can decide whether or not it is sane for us to have
used those pages for the stack, right?

Another question, is at address 0x55555555457f. I presume that
%fs:0x28 is a memory address that points to a sentinel value. We load
it into %rax, and then we store it in strategic locations in our stack
to serve as sentinel values. Before we leave, we check that the memory
location hasn't changed at 0x55555555459f. That implies, that the
memory location %fs:0x28 is pointing to a globally-used sentinel
value?

But who sets %fs? Indeed what is the ABI usage of %fs in the context
of linux x86_64?
And why 0x28 offset?

Thankyou for reading,
Maxim

             reply	other threads:[~2020-03-03 14:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03 14:53 Maxim Blinov [this message]
2020-03-03 16:51 ` Ruslan Kabatsayev
     [not found]   ` <CADmoyEgaCKp3nNg1Yw_8R2QDhEpd3cuaTSFDNFzSiesqerwrWQ@mail.gmail.com>
2020-03-03 18:43     ` Fwd: " Maxim Blinov
2020-03-03 20:03       ` Ruslan Kabatsayev
2020-03-04  9:36 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADmoyEiiCOqjvkydY+OQUN+hVBKidLXDc7A4o+fZgRj3meUAYw@mail.gmail.com \
    --to=maxim.blinov@embecosm.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).