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.
next prev 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: linkBe 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).