public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
Date: Wed, 02 Dec 2020 14:37:45 +0000	[thread overview]
Message-ID: <bug-26991-4717-wi5lsTQ8Lg@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-26991-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=26991

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
The mechanism of the test (as demonstrated on -m64) is as follows:
- use -mmpx -fcheck-pointer-bounds to generate pointer checks in the exec
- run the exec to after all mallocs are done, such that all variables are valid
- do inferior calls, similar to those already in the program
- a peculiarity about inferior calls is that the bounds (that is, the registers
  bnd0-3) are reset at the start of the call, see amd64_push_dummy_call
- first two inferior calls are done (default_run and verify_default_values,
where
  the memory access are done with the bounds registers set by 
  amd64_push_dummy_call to all-allowed
- then we try to do an inferior call with modified bounds registers.
  In order to do that, we set a breakpoint at *function before doing the
inferior
  call.  Once we hit the breakpoint during the inferior call, the bounds
  registers are set to none-allowed, and we continue expecting to run into an
  bounds check sigsegv.

This doesn't work for -m32 because the abi seems different.

For -m64 we have before a regular call the bnd regs setup like this:
...
(gdb) p $bnd0
$5 = {lbound = 0x7fffffffdb70, ubound = 0x7fffffffdb83} : size 20
(gdb) p &sa
$7 = (int (*)[5]) 0x7fffffffdb70
...
by this code:
...
      *x = upper (sa, sb, sc, sd, 0);  /* bkpt 1.  */
  4006ef:       48 8d 8d 60 ff ff ff    lea    -0xa0(%rbp),%rcx
  4006f6:       48 8d 55 80             lea    -0x80(%rbp),%rdx
  4006fa:       48 8d 75 a0             lea    -0x60(%rbp),%rsi
  4006fe:       48 8d 45 c0             lea    -0x40(%rbp),%rax
  400702:       41 b8 00 00 00 00       mov    $0x0,%r8d
  400708:       66 0f 1a 9d f0 fe ff    bndmov -0x110(%rbp),%bnd3
  40070f:       ff
  400710:       66 0f 1a 95 00 ff ff    bndmov -0x100(%rbp),%bnd2
  400717:       ff
  400718:       66 0f 1a 8d 10 ff ff    bndmov -0xf0(%rbp),%bnd1
  40071f:       ff
  400720:       66 0f 1a 85 20 ff ff    bndmov -0xe0(%rbp),%bnd0
  400727:       ff
  400728:       48 89 c7                mov    %rax,%rdi
  40072b:       f2 e8 bb 02 00 00       bnd callq 4009ec <upper>
...

But for -m32, we have instead this (the &sa address is in bnd3, but that's just
used as temporary):
...
(gdb) p $bnd0
$1 = {lbound = 0x804c1e0, ubound = 0x804c1f3} : size 20
(gdb) p &sa
$2 = (int (*)[5]) 0xffffcdf4
(gdb) p $bnd1
$3 = {lbound = 0xffffcde0, ubound = 0xffffcdf3} : size 20
(gdb) p $bnd2
$4 = {lbound = 0x804c1e0, ubound = 0x804c1f3} : size 20
(gdb) p $bnd3
$5 = {lbound = 0xffffcdf4, ubound = 0xffffce07} : size 20
...
because the bounds are passed in the bounds table:
...
      *x = upper (sa, sb, sc, sd, 0);  /* bkpt 1.  */
 80485ed:       83 ec 20                sub    $0x20,%esp
 80485f0:       89 e0                   mov    %esp,%eax
 80485f2:       c7 40 10 00 00 00 00    movl   $0x0,0x10(%eax)
 80485f9:       8d 55 90                lea    -0x70(%ebp),%edx
 80485fc:       89 50 0c                mov    %edx,0xc(%eax)
 80485ff:       8d 55 a4                lea    -0x5c(%ebp),%edx
 8048602:       89 50 08                mov    %edx,0x8(%eax)
 8048605:       8d 55 b8                lea    -0x48(%ebp),%edx
 8048608:       89 50 04                mov    %edx,0x4(%eax)
 804860b:       8d 55 cc                lea    -0x34(%ebp),%edx
 804860e:       89 10                   mov    %edx,(%eax)
 8048610:       8d 50 0c                lea    0xc(%eax),%edx
 8048613:       8b 48 0c                mov    0xc(%eax),%ecx
 8048616:       66 0f 1a 8d 58 ff ff    bndmov -0xa8(%ebp),%bnd1
 804861d:       ff
 804861e:       0f 1b 0c 0a             bndstx %bnd1,(%edx,%ecx,1)
 8048622:       8d 50 08                lea    0x8(%eax),%edx
 8048625:       8b 48 08                mov    0x8(%eax),%ecx
 8048628:       66 0f 1a 9d 60 ff ff    bndmov -0xa0(%ebp),%bnd3
 804862f:       ff
 8048630:       0f 1b 1c 0a             bndstx %bnd3,(%edx,%ecx,1)
 8048634:       8d 50 04                lea    0x4(%eax),%edx
 8048637:       8b 48 04                mov    0x4(%eax),%ecx
 804863a:       66 0f 1a 8d 68 ff ff    bndmov -0x98(%ebp),%bnd1
 8048641:       ff
 8048642:       0f 1b 0c 0a             bndstx %bnd1,(%edx,%ecx,1)
 8048646:       8b 10                   mov    (%eax),%edx
 8048648:       66 0f 1a 9d 70 ff ff    bndmov -0x90(%ebp),%bnd3
 804864f:       ff
 8048650:       0f 1b 1c 10             bndstx %bnd3,(%eax,%edx,1)
 8048654:       f2 e8 e5 02 00 00       bnd call 804893f <upper>
...

So, setting the bounds registers at function entry has no effect, because the
bounds are passed in the bounds table instead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2020-12-02 14:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 13:49 [Bug testsuite/26991] New: " vries at gcc dot gnu.org
2020-12-01 13:54 ` [Bug testsuite/26991] " vries at gcc dot gnu.org
2020-12-02 13:27 ` vries at gcc dot gnu.org
2020-12-02 14:37 ` vries at gcc dot gnu.org [this message]
2020-12-03 14:28 ` [Bug tdep/26991] " vries at gcc dot gnu.org
2020-12-04 12:03 ` [Bug testsuite/26991] " vries at gcc dot gnu.org
2020-12-04 14:22 ` vries at gcc dot gnu.org
2020-12-11 17:26 ` cvs-commit at gcc dot gnu.org
2020-12-11 17:29 ` vries at gcc dot gnu.org

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=bug-26991-4717-wi5lsTQ8Lg@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@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).