[BitVisor-users-en:74] Re: Panic on Windows 11

[Hideki EIRAKU]

Hi,

I created a patch fixing the MOV CR emulation.  Not only
CR0.WP+CR4.CET issue, but some other exception cases are also handled
in this patch.  I hope this makes Windows 11 work with recent
processors.

-- 
Hideki EIRAKU <hdk at igel.co.jp>

From: Hideki EIRAKU <hdk at igel.co.jp>
Subject: Re: [BitVisor-users-en:70] Panic on Windows 11
Date: Tue, 29 Jul 2025 19:11:11 +0900 (JST)

> Hi,
> 
> Thank you for testing and making the patch.  I am thinking about the
> same issue exists in AMD SVM too.  I could not find description about
> what happens when CR0.WP is cleared during CR4.CET=1 in the Intel
> Software Developer's Manual, but AMD's manual clearly says "attempting
> to clear WP to 0 causes a general-protection exception (#GP)."
> 
> The BitVisor implementation has several codes that handle a MOV CR
> instruction.  I think adding cpu_emul_mov_cr function (or
> cpu_emul_write_control_register function, maybe) to handle such
> illegal case as a return value in common, and the function should be
> used in EXIT_QUAL_CR_TYPE_MOV_TO_CR case in VT-x, do_readwrite_cr() in
> SVM, and opcode_mov_to_cr() in cpu_interpreter.c.
> 
> Another quick workaround idea is that probably CR0_WP_BIT in
> current->u.vt.cr0_guesthost_mask could be cleared in
> core/x86/vt_paging.c:vt_paging_init(), in case of unrestricted guest
> is enabled.  Maybe this is not only workaround, but good to improve
> performance in some cases.
> 
> -- 
> Hideki EIRAKU <hdk at igel.co.jp>
> 
> From: "A.S." <an4smith at gmail.com>
> Subject: Re: [BitVisor-users-en:70] Panic on Windows 11
> Date: Fri, 18 Jul 2025 22:30:08 +0300
> 
>> Dear Mr.Eiraku,
>> 
>> I have run the test to confirm the supposed behaviour without the
>> hypervisor -
>> the real hardware generated #GP in this case.
>> 
>> On earlier CPUs the bit CR4.CET was reserved (read as 0),
>> thus not causing the issue.
>> 
>> I have added check in do_mov_cr and injection of #GP in case of violation.
>> The issue appears to be fixed.
>> Sending patch.
>> Could you please review the change?
>> 
>> --
>> =============
>> Best regards,
>>   Dmitriy
>> 
>> вт, 15 июл. 2025 г. в 04:37, Hideki EIRAKU <hdk at igel.co.jp>:
>> 
>>> Hi,
>>>
>>> > RAX 80040033    RCX 80050033    RDX 00000000    RBX 00000001
>>>
>>> > CR0 80040033    CR2 FFFFCF8381ADD000    CR3 0032C000    CR4 00B50EF8
>>>
>>> The log contains interesting CR0 values.  Only the guest CR0 of CPU8
>>> is 80040033H while the guest CR0 of others are 80050033.  The
>>> different bit 16 is WP bit.  The value is also in RAX, so maybe CR0 is
>>> just set by mov %rax,%cr0 instruction.  Maybe.  I did not know about
>>> the case that recent operating systems clear WP bit.
>>>
>>> Intel(R) 64 and IA-32 Architectures Software Developer's Manual says
>>> the following check is performed during VM Entry, described in "Checks
>>> on Guest Control Registers, Debug Registers, and MSRs" section:
>>>
>>> > If bit 23 in the CR4 field (corresponding to CET) is 1, bit 16 in the
>>> CR0 field (WP) must also be 1.
>>>
>>> The bit 23 in the guest CR4 value, 00B50EF8, is 1.  Therefore this
>>> might cause the panic.  BitVisor currently does not handle such case
>>> correctly.  The Intel manual also says the CR0.CET "must be clear
>>> before CR0.WP can be cleared" so the guest behavior looks illegal, but
>>> VMM needs to do something for such illegal case i.e. generating
>>> general protection exception, ignoring the modification, etc. like a
>>> real processor.
>>>
>>> --
>>> Hideki EIRAKU <hdk at igel.co.jp>
>>>
>>> From: "A.S." <an4smith at gmail.com>
>>> Subject: [BitVisor-users-en:70] Panic on Windows 11
>>> Date: Tue, 15 Jul 2025 01:07:55 +0300
>>>
>>> > Hi,
>>> >
>>> > I experience Bitvisor panic when trying to startup Windows 11 after
>>> loading
>>> > Bitvisor.
>>> > Platform: 12th Gen CPU, Chipset: Q670
>>> > Older hardware and older OS runs fine.
>>> > Logs with panic in attachment.
>>> > Could you please help diagnose and possibly fix the problem?
>>> >
>>> > --
>>> > =========
>>> > Best Regards,
>>> >   Dmitriy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-movcr.patch
Type: text/x-patch
Size: 9604 bytes
Desc: not available
URL: <http://www.bitvisor.org/archives/bitvisor-users-en/attachments/20250805/e4b1bbd1/attachment.bin>