linux-kernel - Re: [ANNOUNCE] Merkey's Kernel Debugger

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 7 Aug 2008 06:45:34 -0600 (MDT)
From:	jmerkey@...fmountaingroup.com
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Jason Wessel" <jason.wessel@...driver.com>,
	"Andi Kleen" <andi@...stfloor.org>, jmerkey@...fmountaingroup.com,
	"Nick Piggin" <nickpiggin@...oo.com.au>,
	"Geert Uytterhoeven" <geert@...ux-m68k.org>,
	"Stefan Richter" <stefanr@...6.in-berlin.de>,
	"Josh Boyer" <jwboyer@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

UPDATE:

As per everyone's recommendations, the debugger has been fully
module-ized, and I have run checkpatch.pl and am cleaning up the slew of
messages checkpatch spits out of its tailpipe.

It would be nice if checkpatch also could FIX those areas it complains about.

I tested kprobes with NMI cross processor calls on SMP and I am unable
to break it, and the module loads and unloads very well.  There is a need
for early initialization of the debugger if someone wants to debug kernel
startup and I am including support for this with another.config option,
but I am concerned about the reliance of kprobes on rcu and if this will
break early init of the debugger.   The code looks ok, but another set of
eyes
would be helpful when I post the next patch series.

I will generate another patch series after I finished cleaning up the
checkpatch.pl report.  I am still going through it.

Also, whoever wrote "/Documentation/volatiles_are_evil" must not have
worked with the busted-ass GNU compiler that optimizes away global
variables and busts SMP dependent code.  I am not going to remove the
volatile declarations needed for SMP coordination in the debugger since
the code breaks when removed.  GCC will cause massive breakage of SMP code
if you do not declare certain variables as volatile.

Whoever wrote that section doesn't understand low level SMP coding for
operating systems design and aparently has not sent over a week running
down an SMP bug only to discover it was caused by the busted-ass GCC
compiler arbitrarily deciding to optimize away a low level flag used to
signal between processors -- I have spent the time running down Stallman's
bugs.

That text should be removed from the kernel or qualified that its
advertising for GCC's malfunctioning optimization code.

Jeff

--
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/