linux-kernel - Re: Firewire debugging tools

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] [day] [month] [year] [list]

Date:	Fri, 31 Jul 2009 07:55:17 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	Jun Koi <junkoi2004@...il.com>, linux-kernel@...r.kernel.org,
	Bernhard Kaindl <bk@...e.de>,
	KGDB Mailing List <kgdb-bugreport@...ts.sourceforge.net>
Subject: Re: Firewire debugging tools - firedump & fireproxy?

On Thu, 2009-07-30 at 16:10 -0500, Jason Wessel wrote:
> Maxim Levitsky wrote:
> > On Thu, 2009-07-30 at 03:31 -0500, Jason Wessel wrote:
> >>
> >> 3) Develop a low level dedicated ethernet debug interface.  If you have
> >> more than one ethernet, or an ethernet device that has multiple hardware
> >> queues, it is plausible to have a dedicated way to talk to a device
> >> which has no restrictions on getting preempted, or used by another part
> >> of the kernel.  This lends itself to an ideal medium for kgdb
> >> communications.
> 
> > Or, even better, to make in possible to switch between a normal, and
> > exclusive mode?  Maybe this cab be done without (or with slight)
> > modifications to network drivers.  Why not to make kgdb own the
> > network device (use it exclusively), but use same interfaces as
> > regular kernel does?
> 
> The key problem is how such a switch is governed between normal and
> exclusive mode works.  If it involves locks kgdboe is not going to
> work reliably from the exception context.
I mean the switch should happen just once, when kgdboe is loaded, and
back when unloaded.


> 
> Having kgdboe directly own an interface and use the same kernel API as
> the network stack won't work out of the box because there is probing,
> interrupt control and lots of other tidbits.  This is a case where the
> polling API needs some work or a dedicated API is needed, because this
> is a case where you really don't want the whole network stack
> involved.  IE it would be nice to be able to debug the networking
> stack with kgdboe.
Sure, but I feel that doing any significant changes to _all_ ethernet
drivers is a huge job.

> 
> Patches which implement new functionality, ideas and discussion about
> any aspect of kernel debugging are always welcome on the kgdb mailing
> list. :-)


Best regards,
	Maxim Levitsky

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