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: <48D39B9F.8010404@option.com>
Date:	Fri, 19 Sep 2008 14:31:27 +0200
From:	Denis Joseph Barrow <D.Barow@...ion.com>
To:	Jason Wessel <jason.wessel@...driver.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

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




Jason Wessel wrote:
> Denis Joseph Barrow wrote:
>> Hi Jason,
>> The problem I believe is very reproducable.
> 
> It can be reproduced quite easily as it is a generic problem that
> appears to have existed for quite a long time.
> 
>> I'm doing nothing special with kgdb just using it to help me with 3g
>> modem driver development & my driver wasn't loaded when the problem
>> occured.  I have the following command in my /boot/grub/menu.lst
>> kernel parameter to enable gdb.
>>
>> kgdboc=/dev/ttyS0,115200 maxcpus=1
> 
> 
> This was the key detail that was missing.  Along with the program and
> other gdb details provided the source of the problem was not too hard
> to track down.
> 
> When you attach to the running program with ptrace (via gdb), it
> interrupts the system call and executing the high level "step" will
> result in gdb executing a number of instruction step operations to try
> to get back to an instruction which corresponds to the next valid line
> of high level source code.
> 
> It was the 3rd or 4th instruction step that jumped back into the
> kernel space because gdb ultimately tries to single step a system call
> in your example.  For the kernel, single stepping a system call is a
> special operation in that the system call must appear to complete
> atomically and the user space ends up on the next user space assembly
> instruction after the system call.  Behind the scenes the kernel
> executes the system call and tracks this condition.
> 
> It appears kgdb needs to account for this condition as well, by simply
> ignoring it when it occurs.
> 
> Please try the attached patch, as it will hopefully address the
> problem.
> 
> Jason.
> 


-- 
best regards,
D.J. Barrow
--
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/