public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
@ 2020-12-01 13:49 vries at gcc dot gnu.org
2020-12-01 13:54 ` [Bug testsuite/26991] " vries at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-01 13:49 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
Bug ID: 26991
Summary: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue
to a bnd violation
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: testsuite
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
I get:
...
Running
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.arch/i386-mpx-call.exp ...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: continue to a bnd violation (the
program exited)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: $bnd2 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: $bnd3 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: $bnd1 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: $bnd2 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: $bnd3 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: bndstatus compare before and
after
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: bndstatus compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndcfgu should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndstatus should not change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndcfgu compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: bndstatus compare before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: continue to a bnd violation (the
program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: access only one position
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: return from the fault
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndcfgu should not
change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndstatus should not
change
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: inferior call stopped
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd1raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd2raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd3raw
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0 lower bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: $bnd0 upper bound set
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndcfgu compare before
and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: bndstatus compare
before and after
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: continue to a bnd
violation (the program is no longer running)
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: access only one
position
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: return from the fault
...
In more detail:
...
(gdb) PASS: gdb.arch/i386-mpx-call.exp: upper_bnd0: bndstatus compare before
and after
continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
p (((void *)$_siginfo._sifields._sigfault.si_addr - (void*)a))/sizeof(int) ==
1^M
$23 = 0^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: access only one position
return^M
#0 0xf7ce5e63 in __libc_start_main () from /lib/libc.so.6^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: return from the fault
....
So, for some reason the bnd violation fail to trigger, and we run to the end of
the inferior call.
When we then call return to return from the fault, we actually return from
main, and after that a lot of FAILs are generated.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
@ 2020-12-01 13:54 ` vries at gcc dot gnu.org
2020-12-02 13:27 ` vries at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-01 13:54 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
With this tentative patch:
...
diff --git a/gdb/testsuite/gdb.arch/i386-mpx-call.exp
b/gdb/testsuite/gdb.arch/i386-mpx-cal
l.exp
index 41abbeebcf..5347eaecc2 100644
--- a/gdb/testsuite/gdb.arch/i386-mpx-call.exp
+++ b/gdb/testsuite/gdb.arch/i386-mpx-call.exp
@@ -138,7 +138,17 @@ proc check_bound_violation {parm parm_type is_positive} {
global u_fault
- gdb_test "continue" "$u_fault.*" "continue to a bnd violation"
+ set have_violation 0
+ gdb_test_multiple "continue" "continue to a bnd violation" {
+ -wrap -re "$u_fault.*" {
+ set have_violation 1
+ pass $gdb_test_name
+ }
+ }
+
+ if { ! $have_violation } {
+ return
+ }
set message "access only one position"
if {$is_positive == 1} {
...
we have instead just:
...
Running
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.arch/i386-mpx-call.exp ...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd1: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd2: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd3: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd0: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd1: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd2: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: lower_bnd3: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_up: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_low: continue to a bnd violation
FAIL: gdb.arch/i386-mpx-call.exp: chars_low_adhoc_parm: continue to a bnd
violation
=== gdb Summary ===
# of expected passes 137
# of unexpected failures 11
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation 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
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-02 13:27 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
As for the remaining failure.
Things are made complicated by the fact that bnd0.lbound and bnd0.ubound are
represented as 32-bit in -m32, while in the hardware they're actually 64-bit.
This is reflected in the types:
...
(gdb) ptype $bnd0
type = struct builtin_type_bound128 {
void *lbound;
void *ubound;
}
(gdb) ptype $bnd0raw
type = struct br128 {
uint64_t lbound;
uint64_t ubound_raw;
}
...
So, the interesting thing is always to print the raw value to see what's
actually written in the hw register.
So, before the FAIL we have:
...
(gdb) p /x $bnd0.lbound = $bnd0.ubound^M
$19 = 0xffffffff^M
(gdb) p /x $bnd0.ubound = 0^M
$20 = 0x0^M
(gdb) p /x $bnd0raw^M
$21 = {lbound = 0xffffffff, ubound_raw = 0xffffffffffffffff}^M
...
Now comparing that with the info found here (
https://www.felixcloutier.com/x86/bndmk ):
...
BND.LB ← SRCMEM.base;
IF 64-bit mode Then
BND.UB ← NOT(LEA.64_bits(SRCMEM));
ELSE
BND.UB ← Zero_Extend.64_bits(NOT(LEA.32_bits(SRCMEM)));
FI;
...
we can see that the value written into ubound_raw is not congruent with how
bndmk would write it.
Using this tentative patch:
...
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 00de4e1ccb..2ea28c68bd 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -3527,6 +3527,8 @@ i386_pseudo_register_write
raw_buf);
upper = ~upper;
+ if (size == 4)
+ upper = upper & 0xffffffff;
/* Set register bits. */
memcpy (raw_buf, &lower, 8);
...
fixes that, but not the FAIL.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation 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
2020-12-03 14:28 ` [Bug tdep/26991] " vries at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-02 14:37 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tdep/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
` (2 preceding siblings ...)
2020-12-02 14:37 ` vries at gcc dot gnu.org
@ 2020-12-03 14:28 ` vries at gcc dot gnu.org
2020-12-04 12:03 ` [Bug testsuite/26991] " vries at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-03 14:28 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|testsuite |tdep
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
` (3 preceding siblings ...)
2020-12-03 14:28 ` [Bug tdep/26991] " vries at gcc dot gnu.org
@ 2020-12-04 12:03 ` vries at gcc dot gnu.org
2020-12-04 14:22 ` vries at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-04 12:03 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|tdep |testsuite
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
` (4 preceding siblings ...)
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
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-04 14:22 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch posted:
https://sourceware.org/pipermail/gdb-patches/2020-December/173768.html
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
` (5 preceding siblings ...)
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
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-12-11 17:26 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=346e7e192370a4d602e14466825c329ed5920c8f
commit 346e7e192370a4d602e14466825c329ed5920c8f
Author: Tom de Vries <tdevries@suse.de>
Date: Fri Dec 11 18:26:40 2020 +0100
[gdb/testsuite] Update gdb.arch/i386-mpx-call.exp for -m32
When running test-case gdb.arch/i386-mpx-call.exp with target board
unix/-m32,
we run into:
...
(gdb) continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd
violation
...
Let's look first for reference at -m64, where the test passes.
The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks
in
the exec. Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
call passes pointer bounds as well as arguments. The call to upper (with
four pointer arguments and an int argument, passed in 5 registers) is
modified
like this:
...
lea -0xa0(%rbp),%rcx
lea -0x80(%rbp),%rdx
lea -0x60(%rbp),%rsi
lea -0x40(%rbp),%rax
mov $0x0,%r8d
+ bndmov -0x110(%rbp),%bnd3
+ bndmov -0x100(%rbp),%bnd2
+ bndmov -0xf0(%rbp),%bnd1
+ bndmov -0xe0(%rbp),%bnd0
mov %rax,%rdi
- callq <upper>
+ bnd callq <upper>
...
passsing the four pointer bounds in bounds registers BND0-3.
The top-level mechanism of the test is as follows:
- run the exec to after all mallocs are done, such that all pointer
variables
are valid
- do inferior calls, similar to those present in the program
The inferior call mechanism doesn't differentiate between a call to a
function
compiled with -fcheck-pointer-bounds, and one without. It merely resets
the
bound registers to all-allowed state (see amd64_push_dummy_call), to make
sure
the checks don't trigger during the inferior call. [ This is the same as
what
happens when executing a call without bnd prefix when the BNDPRESERVE bit
of
the BNDCFG register is set to 0, a provision for calling an instrumented
function using a non-instrumented call. ]
First, two inferior calls are done (default_run and verify_default_values)
with the bound registers unmodified by the test. So, the memory accesses
are
performed with the bounds registers set by amd64_push_dummy_call to
all-allowed, and the bounds checks do not trigger.
Then we try to do an inferior call with modified bounds registers, set to
none-allowed. In order to do that, we set a breakpoint at *upper 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 triggered bounds check, which takes the shape of a sigsegv.
Back to -m32. Here, the pointer arguments are passed in memory rather than
registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
the Bounds Table using bndstx:
...
movl $0x0,0x10(%eax)
lea -0x70(%ebp),%edx
mov %edx,0xc(%eax)
lea -0x5c(%ebp),%edx
mov %edx,0x8(%eax)
lea -0x48(%ebp),%edx
mov %edx,0x4(%eax)
lea -0x34(%ebp),%edx
mov %edx,(%eax)
lea 0xc(%eax),%edx
mov 0xc(%eax),%ecx
bndmov -0xa8(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
lea 0x8(%eax),%edx
mov 0x8(%eax),%ecx
bndmov -0xa0(%ebp),%bnd3
bndstx %bnd3,(%edx,%ecx,1)
lea 0x4(%eax),%edx
mov 0x4(%eax),%ecx
bndmov -0x98(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
mov (%eax),%edx
bndmov -0x90(%ebp),%bnd3
bndstx %bnd3,(%eax,%edx,1)
bnd call 804893f <upper>
...
Again, the bounds registers are reset at the start of the inferior call by
amd64_push_dummy_call, and modified by the test-case, but neither has any
effect. The code in upper reads the pointer bounds from the Bounds Table,
not
from the bounds registers.
Note that for a test.c with an out-of-bounds access:
...
$ cat test.c
void foo (int *a) { volatile int v = a[1]; }
int main (void) { int a; foo (&a); return 0; }
$ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
$ ./a.out
Saw a #BR! status 1 at 0x804848d
...
and inferior call foo (&a) right before "bnd call foo" (at the point that
the
bounds for a are setup in the bounds table) doesn't trigger a bounds
violation:
...
(gdb) call foo (&a)
(gdb)
...
This is because the bounds table doesn't associate a pointer with bounds,
but
rather a pair of pointer and pointer location. So, the bound is setup for
&a,
with as location the pushed argument in the frame. The inferior call
however
executes in a dummy frame, so the bound is checked for &a with as location
the
pushed argument in the dummy frame, which is different, so the bounds check
doesn't trigger.
In conclusion, this is expected behaviour.
Update the test-case to not expect to override effective pointer bounds
using
the bounds registers when the bounds passing is done via the Bounds Table.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26991
* gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
violations by setting bounds registers if the bounds are passed in
the
Bounds Table.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug testsuite/26991] FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation vries at gcc dot gnu.org
` (6 preceding siblings ...)
2020-12-11 17:26 ` cvs-commit at gcc dot gnu.org
@ 2020-12-11 17:29 ` vries at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: vries at gcc dot gnu.org @ 2020-12-11 17:29 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=26991
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.1
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch fixed test-case committed, marking resolved-fixed.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-12-11 17:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-01 13:49 [Bug testsuite/26991] New: FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation 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
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
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).