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

Message-ID: <47B5F7B3.6010607@windriver.com>
Date:	Fri, 15 Feb 2008 14:36:03 -0600
From:	Jason Wessel <jason.wessel@...driver.com>
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

Linus Torvalds wrote:
> [ 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

HW breakpoints (particularly data breakpoints) are extremely useful
and I am proposing to put them back into kgdb-light. The HW
breakpoint patch worked exactly as described. If the user space
writes into the HW breakpoint registers via ptrace, those take
priority over the kernel HW breakpoints.

We have to assume that the person debugging the kernel ultimately has
full control of the system, and will do what ever is needed to
debug/inspect the kernel how he or she chooses.

Of course at some future time if there is a generic API to use for the
kernel level HW breakpoints, kgdb can adapt like anything else.

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/