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: <47B1C76F.6070908@windriver.com>
Date:	Tue, 12 Feb 2008 10:21:03 -0600
From:	Jason Wessel <jason.wessel@...driver.com>
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>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] kgdb-light -v10

Andi Kleen wrote:
>> Basically when you reach this chunk of code it is before the hand off
>> to the source debugger.  We cannot continue because there was a
>> breakpoint in a part of the system kgdb was using while doing its
>> normal work.  The reality is that KGDB is not self contained.  It
>> relies on some external I/O methods, atomic page fault handling and
>> some other pieces.  If you take an exception there, the kgdb integrity
>> check absolutely needs to fail.
>>     
>
> Don't you just need a simple recursion counter for this? 
>
> I cannot think of a reliable simple way to check for this using the instruction
> pointer. The only way would be to use explicit annotations for all
> possible code similar to what kprobes does (__kprobes), but that would be 
> hugely intrusive all over the tree.
>
> With the recursion counter the only problem would be someone 
> setting a break point on the early notifier code itself that contains
> a recursion check, but that would be only a few lines of code
> so the risk of someone setting a break point exactly there would
> be low.
>   

It is more than a simple recursion check (which is already in the code)
because there are some conditions we can recover from.  I'd rather not
crash the system out if it can be recovered.

kgdb_reenter_check() has the "simple" recursion check with the
exception_level variable.

It also has several special checks against the breakpoint situation I
described before as well as trying to remove all the breakpoints.  
Ultimately if all those checks fails, it results in panic, because at
the end of the day that is all you can do if you re-enter the debugger
from the debugger (IE: you are toast).

I don't see any reason to change the code there unless it can be further
improved some way.  We want to fail loudly and verbosely when this kind
of thing happens so we can determine if it was the end user that caused
the problem or if there is a real defect.

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/