#GP on vmxon because cr0/cr4 fixed bits are not set

[sduverger]

Hi,

The hax_create_vm() function when invoking invept() and then invept_smpfunc(), does not ensure before a "vmxon" that the fixed bits in CR0/CR4 are correctly set. It results in a general protection exception.

This may not happen under MacOS or Windows, because host CR0 is set by default with ET and NE. But trying to use HAXM in another environment can trigger the bug.

[YuleiWang]

Hi, what's your host OS? Now HAXM only supports Windows and Mac host.

[sduverger]

Hi,

Actually there is no host OS since i've done a fork of HAXM to develop a bare-metal implementation which i'll publish soon. The minimalistic OS integrates "bare-metal haxm" and does not set the same defaults bits in the control registers.

However i would understand that given the fact you "only support" Window and Mac Hosts and that they have these bits set at HAXM start up, you would not fix HAXM. But if one day, these kernels change maybe it'll raise a #GP.

IMHO it's really costless to ensure that CR0/CR4 fixed bits are set before a vmxon, plus it follows Intel SDM :)

Thanks for you answer.

[raphaelning]

Thanks for catching this bug in the code! I'll see if I can ask a teammate to implement the proper check next week, since I'm busy with other tasks. We'd also love to see a PR from you since you've probably fixed the same bug in your project, but we shouldn't ask too much from you :) Anyway, I'm really glad to hear you were able to adapt HAXM into a type-1 hypervisor, and I look forward to your open source release!

[sduverger]

You're welcome. I should have sent you a PR actually, you're right :). If nothing hurry i'll manage to send you something in the following weeks.