linux-kernel - Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140409230114.GB8370@localhost>
Date:	Thu, 10 Apr 2014 07:01:14 +0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Jet Chen <jet.chen@...el.com>, Paolo Bonzini <pbonzini@...hat.com>,
	Borislav Petkov <bp@...en8.de>
Cc:	"Romer, Benjamin M" <Benjamin.Romer@...sys.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

CC the KVM people: it looks like a KVM problem that can be triggered by

        qemu-system-x86_64 -cpu Haswell,+smep,+smap

On Thu, Apr 10, 2014 at 01:58:18AM +0800, Jet Chen wrote:
> On 04/09/2014 10:44 PM, Romer, Benjamin M wrote:
> > On Wed, 2014-04-09 at 02:38 +0800, Jet Chen wrote:
> > 
> >> Hi Ben,
> >>
> >> I checked my <Intel 64 and IA-32 Architectures Software Developer's Manual> which published in Feb 2014.
> >> Volume 2: Instruction Set Reference, A-Z: CPUID--CPU Identification
> >>
> > 
> > I agree completely, which is why I'm confused about KVM's behavior. If
> > bit 31 was off, the code in our drivers that uses the vmcall instruction
> > would not have been run, the kernel would not have tried to perform a
> > vmcall, and not crashed with invalid op.
> > 
> > If you look in the definition for the VMCALL instruction (Intel 64 and
> > IA32 Architectures Software Developer's Manual, volume 3C pg.30-9)
> > You'll see that a processor in VMX non-root operation should perform a
> > vmexit.
> > 
> >> Why this document not match what you said ? I am not experienced with VM, please correct me if I went for wrong document
> >>
> > 
> > According to VMWare's documentation (there is a page at
> > http://kb.vmware.com./selfservice/microsites/search.do?cmd=displayKC&externalId=1009458 ) , as well as Microsoft's hypervisor spec (at http://www.microsoft.com/en-us/download/details.aspx?id=39289 ), this bit is used to indicate the CPU is running under virtualization. KVM is also setting this bit to indicate virtualization. I believe Xen uses it as well.
> > 
> > 
> > My contention is, if KVM is going to set the ISVM bit, it needs to do a
> > vmexit, and if it's not going to set the bit, then doing an invalid op
> > is okay, but the current behavior is inconsistent.
> > 
> > -- Ben
> > 
> 
> Ben,
> 
> Really thanks for your explanation.
> Let me summary it up, please correct me where i am wrong. If it is really a KVM bug, we report it to KVM guys.
> On a real CPU, ECX 31bit always be 0 as Intel documentation filed.
> However, KVM, as a hypervisor, should emulate this bit of the virtual ECX register to 1 for guest OS to indicate it is running in a virtualization environment.
> Problem is, KVM does set this bit to 1, but does an invalid op instead of emit a VMCALL. As a result, we get this dmesg error messages.
> 
> Thanks,
> -Jet
--
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/