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 08:25:05 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	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

On Tue, 12 Feb 2008, Andi Kleen wrote:
> > 
> > KGDB does a very straightforward "all CPUs enter controlled state" 
> > transition when the session begins, and at the end an "all CPUs 
> > continue" transition.
> 
> 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.

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 
simply not _possibly_ be able to even tell or care (which is why 
breakpoint reservations are out - they are against the whole point of 
debugging a unmodified kernel).

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.

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.

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

  If the debugger screws up the hw breakpoint state, that's a debugger 
  error. I'd hope that the remote debugger *defaults* to just re-writing 
  the instruction stream for that reason, but if you want to do a data 
  breakpoint, you simply *have* to use the hw breakpoints for kgdb.

  And you just need to live with the fact that it simply won't be possible 
  to do if the client wants to use hw breakpoints too. If the client 
  starts using hw breakpoints - tough titties, it takes them. ]

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.

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