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: <20080212164244.GA24207@elte.hu>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ