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: <47A1DE37.9060202@web.de>
Date:	Thu, 31 Jan 2008 15:41:59 +0100
From:	Jan Kiszka <jan.kiszka@....de>
To:	george@...dturkeyranch.net
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

George Anzinger wrote:
> 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.

Meanwhile I realized that there is early_trap_init - for x86-32 only! I
assume now we are only lacking the same for x86-64 to get kgdb running
there already during early_param-parsing.

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