linux-kernel - Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung unless gdb remotely attached on x86 & cont is issued

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48D3A1B4.8000505@windriver.com>
Date:	Fri, 19 Sep 2008 07:57:24 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Denis Joseph Barrow <D.Barow@...ion.com>
CC:	KGDB Mailing List <kgdb-bugreport@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, gareth@...inux.com,
	markus.t.metzger@...el.com
Subject: Re: getting false SIGTRAP breakpoints in kernel i.e. kernel hung
 unless gdb remotely attached on x86 & cont is issued

Denis Joseph Barrow wrote:
> Hi Jason,
> Sorry for nitpicking & a big thanks for your patch.
> While this patch stops the big problem, the kernel halting, gdb
> debugging the userland code still doesn't behave correctly
> now. Trying to stepi over a sysenter call in gdb doesn't return
> to the gdb debugger ctrl-c in the debugger still works however.
> Some code probably needs to be also fixed in arch/x86/kernel/ptrace.c
> or ideally the generic kernel/ptrace.c, seeing as this works
> with gdb on a normal kernel it's not a gdb issue even if
> it can be kludge fixed there.
> I'm running GNU gdb 6.8-debian from ubuntu 8.04 hardy heron
>
>

The patch I sent is not yet included the kgdb stream because I was
waiting for further comment.  I do not see any issues however in the
case that you describe, so I will describe how I tested it and then
perhaps you can explain further the case that does not work.

Given that I still had your test program, I used it to set a
breakpoint at read(), after performing an attach as you described
previous with attaching to the running process.  At this point kgdboc
is loaded and configured.

gdb commands:

att PID_OF_randsleep
break read
continue

At this point to hit the breakpoint, I had to type some input on the
ttyS0 which randsleep where randsleep was connected.  At that point I
was able to step the system call with enough "si" commands.  In the
example shown below I did have to provide some more input after the
"si" for address 0xffffe419 so that the system call would come out of
the sleep state because it happened to be a blocking read.

Example:
(gdb) continue
Continuing.

Breakpoint 1, 0x08056b30 in read ()
(gdb) si
0x08056b38 in read ()
(gdb)
0x08056b3a in __read_nocancel ()
(gdb)
0x08056b3b in __read_nocancel ()
(gdb)
0x08056b3f in __read_nocancel ()
(gdb)
0x08056b43 in __read_nocancel ()
(gdb)
0x08056b47 in __read_nocancel ()
(gdb)
0x08056b4c in __read_nocancel ()
(gdb)
0xffffe414 in __kernel_vsyscall ()
(gdb) disas $pc $pc+8
Dump of assembler code from 0xffffe414 to 0xffffe41c:
0xffffe414 <__kernel_vsyscall+0>:       push   %ecx
0xffffe415 <__kernel_vsyscall+1>:       push   %edx
0xffffe416 <__kernel_vsyscall+2>:       push   %ebp
0xffffe417 <__kernel_vsyscall+3>:       mov    %esp,%ebp
0xffffe419 <__kernel_vsyscall+5>:       sysenter
0xffffe41b <__kernel_vsyscall+7>:       nop  
End of assembler dump.
(gdb) si
0xffffe415 in __kernel_vsyscall ()
(gdb)
0xffffe416 in __kernel_vsyscall ()
(gdb)
0xffffe417 in __kernel_vsyscall ()
(gdb)
0xffffe419 in __kernel_vsyscall ()
(gdb)
0xffffe424 in __kernel_vsyscall ()
(gdb)

At least this case appears to work fine with or without kgdb
loaded.  Perhaps you have a different case you can describe?

Thanks,
Jason.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/