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]

Date:	Tue, 12 Feb 2008 17:42:44 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, 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

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> > Yes and the session has no fixed time limit.
> 
> Quite frankly, if kgdb starts doing somethign "fancy", there is no way 
> I'll merge it.
> 
> 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.

yes - i zapped hw breakpoint support in -v10 already.

> In other words: I think the kgdb patches have become a lot more 
> palatable over the last week, but I think so exactly because they have 
> gotten smaller and less invasive. Anything that evokes any discussion 
> AT ALL should just be removed. It really should be that simple.

yes, that's what i've been doing. When anything became questionable even 
just a little bit, it was the axe or i changed it to something really 
obvious and correct.

by 2.6.26 kgdb-light will become so neutral to the rest of the kernel 
that we wont even notice that we've merged it ;-)

> [ The exception being that I think hw breakpoint support should be
>   added back in - never mind that it won't work if the "native kernel" 
>   also uses them. Tough.

yeah. I believe we need to achieve a "known zero impact, 100% trustable" 
state for KGDB to start with, and add stuff carefully to it.

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

yes - if something locks up, it will be the NMI watchdog starting the 
debugger eventually - not the other way around. The NMI watchdog is 
already system policy which can be turned on/off and is well known and 
expresses the user's wishes with what should happen to the system.

The debugger should really be a fundamentally very passive "console" 
type of thing, with as little direct policy as possible. That minimizes 
the chance that it accidentally messes up something and also makes it 
more likely that it will actually work reliably and dependably.

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