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: <48D26B64.5080605@windriver.com>
Date:	Thu, 18 Sep 2008 09:53: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
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,
> 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.

View attachment "user_space_single_step_check.patch" of type "text/x-diff" (1263 bytes)