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
| ||
|
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/
Powered by blists - more mailing lists