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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 8 Aug 2008 07:08:13 -0500
From:	Cliff Wickman <cpw@....com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Vivek Goyal <vgoyal@...hat.com>, Keith Owens <kaos@....com.au>,
	Jay Lan <jlan@....com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	jmerkey@...fmountaingroup.com,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org,
	Takenori Nagano <t-nagano@...jp.nec.com>,
	Bernhard Walle <bwalle@...e.de>
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

On Fri, Aug 08, 2008 at 04:29:16AM +0200, Andi Kleen wrote:
> > panic() is the only place where kdump gets a chance to run first and
> > panic notifiers are not executed.
> 
> To be fully clear panic() that is called outside oops/exception context
> 
> s/panic/die notifiers/
> 
> > 
> > To me so far only in kernel debugger seems to be a reasonable candiate
> 
> Yes a kernel debugger should be able to hook into panic()
> 
> In fact it can do that already by just setting a break point,
> but clearly having a real notifier is preferable.
> 
> The use case would be then that the kernel debugger would
> have some command to trigger a dump.
> 
> > which needs to run before kdump after a panic event. If a debugger
> > is really getting merged into the kernel, then I think debugger can
> 
> kgdb is already merged. Also the x86 notifiers are general
> enough that there are a couple of debuggers floating around
> that are just using existing interfaces (as in need very little in terms
> of core patching) 
> 
> > put a hook in the panic() before kdump. Wouldn't this solve the problem?
> 
> Yes it would, but right now there is no such hook. Also if there 
> was such a hook kdump could use it like everyone else.  

Agree.
And here is another example of the need for such a hook:

In a partitioned system [I work for SGI, so I'm talking about an Altix],
there is memory sharing among multiple single-system images. And if
one of those partitions were to panic the other partitions need to
be informed that they cannot address the panic'd partition's memory.
(Once that partition is rebooted any such access will cause an MCA
in the accessor.)

So the cross-partition driver (xpc) needs to run a callback there, too.
It seems to me, as Keith has voiced, that it should be the user's choice
to run something there.

> There's a priority scheme in notifiers so you can still run usually last.
> 
> -Andi
> --
> 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/

-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw@....com
(651) 683-3824
--
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/