You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(4) |
2
(7) |
3
(29) |
4
(2) |
|
5
(2) |
6
(14) |
7
(4) |
8
(17) |
9
(19) |
10
(17) |
11
(18) |
|
12
(21) |
13
(22) |
14
(16) |
15
(14) |
16
(2) |
17
|
18
(3) |
|
19
|
20
(1) |
21
(14) |
22
(9) |
23
(13) |
24
|
25
|
|
26
(1) |
27
(12) |
28
(2) |
29
(17) |
30
(14) |
31
(5) |
|
|
From: Philippe W. <phi...@sk...> - 2013-05-01 20:39:31
|
On Wed, 2013-05-01 at 17:55 +0100, Tom Hughes wrote:
> On 01/05/13 17:31, Philippe Waroquiers wrote:
>
> > When the inferior function returns, in an execution under GDB or an
> > execution under a "normal" gdbserver, the breakpoint is encountered
> > before the instruction is executed. GDB regains control, and restore
> > the situation before the inferior function call.
>
> So normally gdb will rely on a hardware breakpoint using the debug
> registers to trigger and the INT3 will never try and execute?
I investigated the behaviour of GDB "native" some more in depth:
The INT3 in a non executable page is effectively never executed.
However, GDB does not use hw breapoints for that.
When the inferior function returns, a SIGSEGV is generated.
GDB however handles this SIGSEGV as a SIGTRAP when there is a
breakpoint at the address that caused the SEGV.
In such a case, GDB instructs the inferior process to ignore
the SEGV.
With the PT_GNU_STACK, Valgrind m_translate.c generates also
a SIGSEGV, properly received by GDB via gdbsrv.
However, in the case of Valgrind, there is no way for V to
ignore the SEGV : ignoring such a SEGV would imply to have
V properly continuing execution somewhere in m_translate.c.
Probably do-able but not straightforward => other solution
in the patch below.
> Or make the valgrind gdbserver support "hardware" breakpoints as I think
> it already does for watchpoints, and have execution stop with SIGTRAP
> when a breakpoint address is hit without valgrind trying to decode and
> execute the instruction?
Valgrind "emulates" hardware watchpoints by using the memcheck
A-bits machinery.
Breakpoints are translated in a call to gdbserver.
V accepts both Z0 and Z1 packets (hard or soft breakpoints)
but they are implemented the same way (and GDB uses Z0 by default).
The patch below fixes the problem of the nx stack by still accepting
to translate when there is a gdbsrv breakpoint at the addr to translate
in an nx segment.
Accepting to translate in such a case will have no effect as
GDB will cleanup before this translation is really executed
(only the gdbserver call at the beginning of the translation is
executed, not the "real" instructions after).
If no comment on the patch, I will commit in one day or two.
Philippe
Index: coregrind/m_translate.c
===================================================================
--- coregrind/m_translate.c (revision 13380)
+++ coregrind/m_translate.c (working copy)
@@ -745,9 +745,9 @@
/* --------- Various helper functions for translation --------- */
/* Look for reasons to disallow making translations from the given
- segment. */
+ segment/addr. */
-static Bool translations_allowable_from_seg ( NSegment const* seg )
+static Bool translations_allowable_from_seg ( NSegment const* seg, Addr addr )
{
# if defined(VGA_x86) || defined(VGA_s390x) || defined(VGA_mips32) \
|| defined(VGA_mips64)
@@ -757,7 +757,16 @@
# endif
return seg != NULL
&& (seg->kind == SkAnonC || seg->kind == SkFileC || seg->kind == SkShmC)
- && (seg->hasX || (seg->hasR && allowR));
+ && (seg->hasX
+ || (seg->hasR && allowR)
+ || VG_(has_gdbserver_breakpoint) (addr));
+ /* If GDB/gdbsrv has inserted a breakpoint at addr, we assume this
+ is a valid location to translate, even if seg not executable.
+ This is needed for inferior function calls from GDB: GDB inserts a
+ breakpoint on the stack, and expects to regain control before the
+ breakpoint instruction at the breakpoint address is really
+ executed. For this, the breakpoint instruction must be translated
+ so as to have the call to gdbserver executed. */
}
@@ -852,7 +861,7 @@
allow a chase. */
/* Destination not in a plausible segment? */
- if (!translations_allowable_from_seg(seg))
+ if (!translations_allowable_from_seg(seg, addr))
goto dontchase;
/* Destination is redirected? */
@@ -1418,7 +1427,7 @@
{ /* BEGIN new scope specially for 'seg' */
NSegment const* seg = VG_(am_find_nsegment)(addr);
- if ( (!translations_allowable_from_seg(seg))
+ if ( (!translations_allowable_from_seg(seg, addr))
|| addr == TRANSTAB_BOGUS_GUEST_ADDR ) {
if (VG_(clo_trace_signals))
VG_(message)(Vg_DebugMsg, "translations not allowed here (0x%llx)"
Index: coregrind/pub_core_gdbserver.h
===================================================================
--- coregrind/pub_core_gdbserver.h (revision 13380)
+++ coregrind/pub_core_gdbserver.h (working copy)
@@ -76,6 +76,9 @@
Bool VG_(gdbserver_point) (PointKind kind, Bool insert,
Addr addr, int len);
+/* True if there is a breakpoint at addr. */
+Bool VG_(has_gdbserver_breakpoint) (Addr addr);
+
/* Entry point invoked by vgdb when it uses ptrace to cause a gdbserver
invocation. A magic value is passed by vgdb in check as a verification
that the call has been properly pushed by vgdb. */
Index: coregrind/m_gdbserver/m_gdbserver.c
===================================================================
--- coregrind/m_gdbserver/m_gdbserver.c (revision 13380)
+++ coregrind/m_gdbserver/m_gdbserver.c (working copy)
@@ -394,6 +394,15 @@
return True;
}
+Bool VG_(has_gdbserver_breakpoint) (Addr addr)
+{
+ GS_Address *g;
+ if (!gdbserver_called)
+ return False;
+ g = VG_(HT_lookup) (gs_addresses, (UWord)HT_addr(addr));
+ return (g != NULL && g->kind == GS_break);
+}
+
Bool VG_(is_watched)(PointKind kind, Addr addr, Int szB)
{
Word n_elems;
|
|
From: tammy j. <jia...@gm...> - 2013-05-01 18:11:45
|
Hi there:
I have using Valgrind to test some programs. It works well. However, it
seems that Valgrind is only a perfect tool to maintain software
reliability. I am thinking recently to add features of security protection.
I wonder to know whether it is acceptable. If you have any opinions, feel
free to tell. Thank you all!.
--
Sincerely:
Tianbin Jiang
|
|
From: Tom H. <to...@co...> - 2013-05-01 16:55:42
|
On 01/05/13 17:31, Philippe Waroquiers wrote: > When the inferior function returns, in an execution under GDB or an > execution under a "normal" gdbserver, the breakpoint is encountered > before the instruction is executed. GDB regains control, and restore > the situation before the inferior function call. So normally gdb will rely on a hardware breakpoint using the debug registers to trigger and the INT3 will never try and execute? > When running under Valgrind: when the called function returns, Valgrind > has to decode and translate the instruction(s) on the stack. > (note: after some discussions with GDB developers, the insertion of > 0xcc/INT3 on the stack by GDB was added especially for Valgrind in GDB > 7.5: without this 0xcc, the stack contains "random" bytes, which caused > Valgrind instruction decoder to report invalid instructions). Right, so it sounds like it was relying on a hardware breakpoint which is why it didn't need the actual instruction but valgrind does. > Maybe when an nx page is detected, have m_translate.c checking if > there is a breakpoint at this address. If there is a breakpoint, > rather generate a SIGTRAP than a SIGSEGV ? Or make the valgrind gdbserver support "hardware" breakpoints as I think it already does for watchpoints, and have execution stop with SIGTRAP when a breakpoint address is hit without valgrind trying to decode and execute the instruction? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2013-05-01 16:31:30
|
On Tue, 2013-04-30 at 18:51 +0100, Tom Hughes wrote: > On 30/04/13 18:04, Julian Seward wrote: > > On 04/18/2013 05:10 PM, Tom Hughes wrote: > >> On 18/04/13 03:02, Tom Hughes wrote: > > > >> These failiures are caused by the change I committed yesterday to > >> respect the PT_GNU_STACK information and make stacks non-executable > >> when possible. > >> > >> It seems that when GDB wants to call a function in the target it is > >> poking an INT3 instruction onto the targets stack, then poking the > >> address of that instruction on to the stack as the return address and > >> resuming at the address of the function it wants to call. > > > > Sounds plausible, but Philippe will know for sure. > > > > Did this get resolved yet? > > No. I was hoping Philippe would have some ideas. Oops, I missed the original mail, so here is some late feedback. > > I did look a bit further at it, and it seems that when the target is run > directly under gdb without valgrind it does things in a different way > and doesn't use the stack as the return address. The i386/amd64 gdb target was changed in GDB 7.5 to use 'ON_STACK' inferior. GDB 7.4 and before are using AT_ENTRY_POINT. With ON_STACK, GDB always uses the stack to insert a breakpoint for the return address of an inferior function call. I do not think that GDB behaves differently when using a gdbserver or when running natively (i.e. GDB does not change the stack permissions). I think the difference of behaviour is due to Valgrind, which has to decode instructions before they are executed. When the inferior function returns, in an execution under GDB or an execution under a "normal" gdbserver, the breakpoint is encountered before the instruction is executed. GDB regains control, and restore the situation before the inferior function call. (not completely sure about the above. If the stack page is not executable, maybe some special code in the kernel will cause SIGTRAP to be generated anyway if there is a INT3 instruction). There is a testcase for "returning" to an nx page at: wget http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ret-to-nxpage.c?cvsroot=systemtap If you compile and run ret-to-nxpage.c (amd64/Deb 6), it works properly natively. It fails under Valgrind. When running under Valgrind: when the called function returns, Valgrind has to decode and translate the instruction(s) on the stack. (note: after some discussions with GDB developers, the insertion of 0xcc/INT3 on the stack by GDB was added especially for Valgrind in GDB 7.5: without this 0xcc, the stack contains "random" bytes, which caused Valgrind instruction decoder to report invalid instructions). The resulting translated instructions will not be executed, as GDB will regain control due to the breakpoint being encountered (a breakpoint at an instruction is translated by Valgrind into a call to the Valgrind gdbserver, to let GDB regain control). With the PT_GNU_STACK making the stack not executable, Valgrind now reports an error and crashes. I checked that the stack permission is not changed by GDB 7.5, on Debian 6: (gdb) bt #0 whoami (msg=0x602010 "hello") at t.c:29 #1 <function called from gdb> #2 main (argc=1, argv=0x7fffffffe678) at t.c:105 (gdb) info frame 0 Stack frame at 0x7fffffffe460: rip = 0x400be8 in whoami (t.c:29); saved rip 0x7fffffffe46f called by frame at 0x7fffffffe468 source language c. Arglist at 0x7fffffffe450, args: msg=0x602010 "hello" Locals at 0x7fffffffe450, Previous frame's sp is 0x7fffffffe460 Saved registers: rbp at 0x7fffffffe450, rip at 0x7fffffffe458 (gdb) x/1xb 0x7fffffffe46f 0x7fffffffe46f: 0xcc (gdb) shell grep stack /proc/16264/maps 7ffffffea000-7ffffffff000 rw-p 00000000 00:00 0 [stack] (gdb) c Continuing. pid 16264 Thread 16264 hello (gdb) So, to have inferior function calls working with PT_GNU_STACK and GDB >= 7.5, it seems something more sophisticated will be needed in Valgrind. Maybe when an nx page is detected, have m_translate.c checking if there is a breakpoint at this address. If there is a breakpoint, rather generate a SIGTRAP than a SIGSEGV ? Or maybe call gdbserver directly ? I will experiment with the above and give feedback. Philippe |