linux-kernel - Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

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:	Thu, 08 Mar 2012 18:48:33 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
Cc:	fernando@....ntt.co.jp, dzickus@...hat.com,
	linux-tip-commits@...r.kernel.org, torvalds@...ux-foundation.org,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	mingo@...hat.com, tglx@...utronix.de, hpa@...or.com, mingo@...e.hu,
	yinghai@...nel.org, akpm@...ux-foundation.org, vgoyal@...hat.com
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

HATAYAMA Daisuke <d.hatayama@...fujitsu.com> writes:

> From: Fernando Luis Vázquez Cao <fernando@....ntt.co.jp>
> Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
> Date: Wed, 07 Mar 2012 19:53:16 +0900
>
>> On 03/01/2012 08:19 AM, Eric W. Biederman wrote:
>> 
>>> Don Zickus<dzickus@...hat.com>  writes:
>>>> It probably is, except I never hacked on idt code before and my
>>>> assembly
>>>> isn't that good.  I have been trying to find examples to copy from to
>>>> give
>>>> it a try.  So far I was using early_idt_handlers with early_printk to
>>>> see
>>>> if I could capture some printk messages while jumping from the first
>>>> kernel to the second kernel (when the other early_idt_handlers would
>>>> kick
>>>> in for the second kernel).
>>>>
>>>> Tips?  Better examples?
>>> That is a particularly good example.  When I took a quick look earlier
>>> that is the first place we reload the idt in the kernel boot so that
>>> is
>>> one of two places that needs to be modified.
>> 
>> Hi Eric, Don
>> 
>> Sorry for chiming in so late.
>> 
>> We run into the same NMI problems and wrote some patches that tackle
>> the kernel boot side of things. They have been extensively tested
>> using
>> qemu-kvm and things seem to be working as expected (after receiving an
>> early NMI the kernel continues without problem; after the iret there
>> is no
>> stack corruption or register corruption).
>> 
>> I will be replying to this email with the patches.
>> 
>
> Should the following also be fixed?

Most definitely.  I think Fernando said he was going to tackle that
next.


Eric


> /*
>  * Do not allocate memory (or fail in any way) in machine_kexec().
>  * We are past the point of no return, committed to rebooting now.
>  */
> void machine_kexec(struct kimage *image)
> {
>         unsigned long page_list[PAGES_NR];
>         void *control_page;
>         int save_ftrace_enabled;
> <cut>
>         /*
>          * The gdt & idt are now invalid.
>          * If you want to load them you must set up your own idt & gdt.
>          */
>         set_gdt(phys_to_virt(0), 0);
>         set_idt(phys_to_virt(0), 0);    <--- This
>
> Thanks.
> HATAYAMA, Daisuke
--
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/