From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/3] Remove interrupt stack table usage from x86_64 kernel Date: Sun, 28 Dec 2008 16:09:26 +0200 Message-ID: <49578896.8030703@redhat.com> References: <1230238726-17506-1-git-send-email-avi@redhat.com> <87vdt5vfxc.fsf@basil.nowhere.org> <4956A0B1.1060908@redhat.com> <20081227224029.GB496@one.firstfloor.org> <49573FE7.9090802@redhat.com> <20081228131605.GC496@one.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: x86@kernel.org, Ingo Molnar , linux-kernel , KVM list To: Andi Kleen Return-path: Received: from mx2.redhat.com ([66.187.237.31]:44601 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754716AbYL1OJu (ORCPT ); Sun, 28 Dec 2008 09:09:50 -0500 In-Reply-To: <20081228131605.GC496@one.firstfloor.org> Sender: kvm-owner@vger.kernel.org List-ID: (restoring cc list) Andi Kleen wrote: > One of the other problems: NMIs and MCEs have the same problem with SYSCALL > This one however looks unsolvable. Userspace can point %rsp into arbitrary memory, issue a syscall, and hope for an nmi. Since we're in cpl 0 and are not using IST, the processor will not switch stacks, and the nmi stack frame will corrupt any memory the user chooses to point to. Even without a malicious user, %rsp could legitimately point at unmapped memory. I don't see how syscall could work on i386, and indeed: > vdso32.so-$(VDSO32-y) += int80 > vdso32.so-$(CONFIG_COMPAT) += syscall > vdso32.so-$(VDSO32-y) += sysenter It's disabled. Is that the reason? -- error compiling committee.c: too many arguments to function