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
| ||
|
Date: Fri, 09 Mar 2012 09:59:02 +0900 ( ) From: HATAYAMA Daisuke <d.hatayama@...fujitsu.com> To: fernando@....ntt.co.jp Cc: ebiederm@...ssion.com, 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 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? /* * 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/
Powered by blists - more mailing lists