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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 8 Apr 2014 10:39:36 -0500
From:	"Romer, Benjamin M" <Benjamin.Romer@...sys.com>
To:	Fengguang Wu <fengguang.wu@...el.com>
CC:	*S-Par-Maintainer <SParMaintainer@...sys.com>,
	Ken Cox <jkc@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Jet Chen <jet.chen@...el.com>
Subject: Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

On Tue, 2014-04-08 at 10:53 +0800, Fengguang Wu wrote:
> Hi Benjamin,
> 
> > Fengguang,
> > 
> > I ran your script against freshly-checked-out source from staging-next, and was not able to reproduce the error with it. My boot log is attached. I noticed that your log did not have "Hypervisor detected: KVM" in the trace. The KVM options in your script also differ substantially from the ones shown at the end of your trace...
>  
> > When I reran your script with the "-cpu Haswell,+smep,+smap" option I was able to get the same result as you. IMHO KVM should not be setting this bit if it's emulating bare metal.
> 
> Sorry.. We tried to provide a simplified reproduce script and in your
> case, it has a significant mismatch with the real KVM options. We'll
> fix it, thanks for pointing it out!
> 
> Thanks,
> Fengguang

That will be helpful, and as I mentioned, I can reproduce your results,
but I'm still not sure why a virtualized processor is giving an invalid
opcode fault on a vmcall. The Intel documentation is pretty specific
about this - IF not in VMX operation THEN #UD; ELSIF in VMX non-root
operation THEN VM exit.

Either KVM should be saying "I'm a real processor and not a virtual CPU,
really!" - in which case, the hypervisor bit should be off and vmcalls
should cause an invalid opcode fault, or, KVM should be saying "I'm a
vritualized processor!" and setting the hypervisor bit, and doing a
vmexit on vmcall instead. This seems like a KVM bug to me.

-- Ben