From: Ruslan Kabatsayev <b7.10110111@gmail.com>
To: Maxim Blinov <maxim.blinov@embecosm.com>
Cc: gdb@sourceware.org
Subject: Re: use of %fs segment register in x86_64 with -fstack-check
Date: Tue, 03 Mar 2020 16:51:00 -0000 [thread overview]
Message-ID: <CAHEcG96OuB4OuQcHAr989feHQA7v7EPpGGgROPV2pok8QP15PA@mail.gmail.com> (raw)
In-Reply-To: <CADmoyEiiCOqjvkydY+OQUN+hVBKidLXDc7A4o+fZgRj3meUAYw@mail.gmail.com>
Hi,
On Tue, 3 Mar 2020 at 17:53, Maxim Blinov <maxim.blinov@embecosm.com> wrote:
>
> 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?
Not quite. As noted at [1] this OR is to ensure that stack hasn't
overflowed. This is the part added by -fstack-check (you can see it go
away when you remove this option). See [2] for documentation.
>
> 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?
Right. But note that this is enabled not by -fstack-check, but rather
by some of the -fstack-protector* options that are on by default on
modern Linux distributions. You can confirm this by explicitly passing
-fno-stack-protector and seeing this sentinel checking gone.
>
> But who sets %fs? Indeed what is the ABI usage of %fs in the context
> of linux x86_64?
The FS segment base points to the TLS. See [3] and links therein.
> And why 0x28 offset?
It's the offset of stack_guard member of tcbhead_t. See the
corresponding glibc source [4].
>
> Thankyou for reading,
> Maxim
[1]: https://stackoverflow.com/a/44670648/673852
[2]: https://gcc.gnu.org/onlinedocs/gccint/Stack-Checking.html
[3]: https://chao-tic.github.io/blog/2018/12/25/tls
[4]: https://code.woboq.org/userspace/glibc/sysdeps/x86_64/nptl/tls.h.html#42
Regards,
Ruslan
next prev parent reply other threads:[~2020-03-03 16:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 14:53 Maxim Blinov
2020-03-03 16:51 ` Ruslan Kabatsayev [this message]
[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=CAHEcG96OuB4OuQcHAr989feHQA7v7EPpGGgROPV2pok8QP15PA@mail.gmail.com \
--to=b7.10110111@gmail.com \
--cc=gdb@sourceware.org \
--cc=maxim.blinov@embecosm.com \
/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).