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

[Hideki EIRAKU]

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