linux-kernel - Re: [Kgdb-bugreport] [PATCH 1/5] KGDB: improve early init

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: <47A1D9AE.4090206@wildturkeyranch.net>
Date:	Thu, 31 Jan 2008 07:22:38 -0700
From:	George Anzinger <george@...dturkeyranch.net>
To:	Jan Kiszka <jan.kiszka@....de>
CC:	Jason Wessel <jason.wessel@...driver.com>,
	Ingo Molnar <mingo@...e.hu>,
	kgdb-bugreport@...ts.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Kgdb-bugreport] [PATCH 1/5] KGDB: improve early init

On 01/31/2008 01:36 AM,  Jan Kiszka was caught saying:
 > Jan Kiszka wrote:
 >> George Anzinger wrote:
 >>> On 01/30/2008 04:08 PM,  Jan Kiszka was caught saying:
 >>>> [Here comes a rebased version against latest x86/mm]
 >>>>
 >>>> In case "kgdbwait" is passed as kernel parameter, KGDB tries to set up
 >>>> and connect to the front-end already during early_param evaluation.
 >>>> This
 >>>> fails on x86 as the exception stack is not yet initialized, 
effectively
 >>>> delaying kgdbwait until late-init.
 >>>
 >>> I wonder how much work it would take to just set up the exception
 >>> stack and proceed.  After all the kgbdwait is there to help debug
 >>> very early kernel code...
 >>
 >> In principle a valid question, but I'm not the one to answer it. I
 >> would not feel very well if I had to reorder this critical setup code.
 >> Look, we would have to move trap_init in start_kernel before
 >> parse_early_param, and that would affect _every_ arch...

I can not speak to other archs, but for x86 I called trap_init from the 
code that caught the kgdbwait.  At that time (since I retired, I have 
not looked at the actual kernel code) it could be called again later by 
the kernel code.  I.e. I did not try to reorder the kernel bring up 
code, but just added an additional call to trap_init and then only in 
the case of finding a kgdbwait.

As such, this would need to be arch specific...

 >>
 >
 > BTW, do you know if EXCEPTION_STACK_READY fails for other archs in
 > parse_early_param as well? It should, because my under standing of
 > trap_init is that it's the functions to arm things like... exception
 > handlers? And that raises the question of the deeper purpose of this
 > check (and the invocation of kgdb_early_init from the argument parsing
 > function). Sigh, KGDB is still a quite improvable piece of code.

Likely.  Once you get it in the main line kernel, one would hope that 
other arch code would be forth coming as many more "eyes" will be in play.
 >
 > Jan
 >
 > PS: Can we move this to some public list?

Sure, sorry I picked the wrong reply button, never intended it to be 
private.
 >

-- 
George Anzinger   george@...dturkeyranch.net


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