Summary: | sys-devel/gdb-7.2 ignores hardware breakpoints and provides no symbolic bt on amd64 hardened | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hugo Mildenberger <Hugo.Mildenberger> |
Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | dschridde+gentoobugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://sourceware.org/bugzilla/show_bug.cgi?id=11908 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Hugo Mildenberger
2010-10-20 11:53:20 UTC
Good news regarding the /proc/<pid>/auxv problem. Spender said on http://forums.grsecurity.net/viewtopic.php?f=1&t=2467 : I'll update the restriction for this so that it's readable only if the task is currently being ptraced and only by the task doing the ptracing. Using the test code from bug #265693#c13, one obtains the exact same results on amd64 nnone hardened gentoo, on unbuntu 10.04 (which uses gdb-7.1) and ubuntu10.10 (which uses gdb-7.2). The reuslts for the later are below. Basically you cannot set hardware breakpoints until after the process is started: basile@carlson-desktop:~/265693$ gdb ./gtest GNU gdb (GDB) 7.2-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/basile/265693/gtest...done. (gdb) hbreak function_1 No hardware breakpoint support in the target. (gdb) run Starting program: /home/basile/265693/gtest Program received signal SIGINT, Interrupt. 0x00007ffff7a8cba5 in raise () from /lib/libc.so.6 (gdb) hbreak function_1 Hardware assisted breakpoint 1 at 0x400548: file gtest.c, line 4. (gdb) cont Continuing. Breakpoint 1, function_1 () at gtest.c:4 4 printf("entering %s\n",__PRETTY_FUNCTION__); (gdb) Hi, I'll try to explain what's involved behind hardware breakpoints and why they aren't working right now before executing a program. I'll also point a few limitations which are good to know. On x86 (and amd64) Hardware breakpoints basically work by modifying the Dr registers, this means that we can have as much 4 breakpoints, amongst other restrictions, and only can turn them on once the program has started running. Ok, now is when you say, then why don't modify them betwen the fork and exec calls. Because the exec call may reset those registers son the breakpoints would disappear. Now comes the part on how to use them. Basically what's needed is storing the hardware breakpoint in the same way as software breakpoints work. IIRC correctly, what is done is put a pending signal before the exec on the child so all of them can be properly set on load and just after the exec call ends. So all we need is add a hook to read the stored breakpoints and set the registers as we do when the program is already running. (In reply to comment #3) > Hi, > > I'll try to explain what's involved behind hardware breakpoints and why they > aren't working right now before executing a program. I'll also point a few > limitations which are good to know. > > On x86 (and amd64) Hardware breakpoints basically work by modifying the Dr > registers, this means that we can have as much 4 breakpoints, amongst other > restrictions, and only can turn them on once the program has started running. > > Ok, now is when you say, then why don't modify them betwen the fork and exec > calls. Because the exec call may reset those registers son the breakpoints > would disappear. > > Now comes the part on how to use them. Basically what's needed is storing the > hardware breakpoint in the same way as software breakpoints work. IIRC > correctly, what is done is put a pending signal before the exec on the child so > all of them can be properly set on load and just after the exec call ends. So > all we need is add a hook to read the stored breakpoints and set the registers > as we do when the program is already running. > Some remarks: when applying that ugly hack I described in comment 13 to BUG #265693, gdb is fully able to use hw breakpoints right from start if the "hbreak" command is used. The "break" command still tries to modify code and therefore fails. From what I've seen in gdb's sources, this behaviour differs from remote targets, where gdb tries to use hardware breakpoints first. There is another interesting inconsistency: gdb's "watch" command silently uses the hardware debug registers, while complaining about no hardware support when trying to use "hbreak". --- The PaX induced problem regarding randmap had been fixed with grsecurity-2.2.0-2.6.35.7-201010201740.patch; thus paxctl -r is not needed any more and gdb-based just-in-time debuggers like drkonqi are finally working on also on hardened platforms. Since we no longer have access to PaX patched kernel to even test this I'm closing as obsolete. Reopen if needed. |