linux-kernel - Re: [git pull] kgdb-light -v10

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: <20080212170711.GB4191@one.firstfloor.org>
Date:	Tue, 12 Feb 2008 18:07:11 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, "Frank Ch. Eigler" <fche@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] kgdb-light -v10

> This includes things like having "breakpoint reservations" (discussed 
> earlier) and just generally trying to add lots of infrastructure to make 
> kgdb "fit in" to the kernel.

I think that part is actually mostly ok now (old kgdb stubs were
much worse in this regard) 

I still think the ultimative proof for this would be working
"modprobe kgdb" though.

> 
> The fact is, not having kgdb enabled should have _zero_ impact on the 
> kernel, but the implication is also that when you *do* enable kgdb, that 
> shouldn't change anything visible either: the rest of the kernel should 

While agreed in theory there are some exceptions: any time an oops
happens or a crash dump would happen automatically kgdb should definitely
do something very visible. Unfortunately that's not always the case
currently (see earlier comments on the notifier priority) 

> So kgdb in my opinion will *have* to step on some other kernel 
> infrastructure. I also think that things like timeouts are not something 
> the client should do - if a kgdb lock never gets through, then it should 
> be the debugging end that should just react to ^C and tough titties: it's 
> not like there's a whole lot to be done.

The problem here is that the timeout we were talking about 
is not integrated into the kgdb event loop, it is rather the loop
that protects the event loop. If you hang there all input
from the outside will be ignored.

> So keep the damn thing really simple, and don't try to handle every 
> possible thing. We expect the debugger side to have a person with some 
> flexibility on it.

If you want areally simple kgdb the best option would be re-porting
the really simple (tm) 2.4 era x86-64 kgdb stub I did long ago.
It had a small fraction of the code size of the current code, but
was also missing a lot of features of course.

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