virtualbox.org

I have used VirtualBox with following conditions.

Host H/W:

• CPU: Intel Core i7 4770S
• M/B: ASUS H87-PRO
• Memory: DDR3 1600 16GB
• Drive: 480GB SATA600 SSD

Host OS:

• Windows 10 version 1909 x68_64

VirtualBox:

• 6.0.14

Guest OS:

• CentOS 6.10, 7.7.1908 x86_64
• Debian 9.11, 10.1, unstable amd64
• FreeBSD 12.1-RELEASE, 13-CURRENT amd64
• Windows 10 version 1909 x86_64

Yesterday I upgraded host H/W as following.

• CPU: Intel Core i7 9700
• M/B: ASUS PRIME H370-A
• Memory: DDR4 2600 32GB
• Drive: 1TB M.2 NVMe SSD

Host OS was copied from old drive to new one and it seemed to work fine. But after H/W upgrade some guest OSes don't start up.

CentOS 7:

• As soon as boot start kernel panics with 'Kernel panic - not syncing: Faital exception'

FreeBSD 12.1-RELEASE:

• 'Guru Mediation' Dialog is displayed with 'A critical error has occurred while running the virtual machine and the machine execution has been stopped.' while kernel is starting.

FreeBSD 13-CURRENT:

• OS hangs up while kernel is starting.

VMs of these OSes are creating before H/W upgrade. So I created new VM and tried to install same OSes. But same problem happened while booting from installer ISO image. I also uninstalled VirtualBox and reinstalled same version. But the problem still happened.

Attached zip archive includes log files (VBox.log and VBoxHardening.log) of each OS.

Then what is wrong? Is it a problem related to new H/W? Or should I make clean install of host OS rather than using one installed for old H/W?.

Best Regards.

There seems to be a common denominator among all of these guests, just before the crash/hang:
[quote=""FreeBSD #1""]

00:00:11.410481 IEM: rdmsr(0x48) -> #GP(0)

[/quote][quote=""FreeBSD #2""]

00:00:19.338933 IEM: rdmsr(0x48) -> #GP(0)

[/quote][quote=""CentOS #1""]

00:00:10.815039 IEM: wrmsr(0x48,0x0`00000001) -> #GP(0)

[/quote]
Take a look at a post from 'fth0' regarding this. The solution is to issue the following command, with the VMs completely shut down:

• 
  VBoxManage modifyvm "FreeBSD #1" --spec-ctrl on
  VBoxManage modifyvm "FreeBSD #2" --spec-ctrl on
  VBoxManage modifyvm "CentOS #1" --spec-ctrl on

PS. For future reference, avoid using "weird" characters in your VM name. The pound sign (#) for example has to be "translated" when forming the VM path into an underscore (_), because a pound cannot be used for a directory name. So your "FreeBSD #1" for example has to be translated to "FreeBSD _1" when creating the VM path on the Host.

Thank you for reply, and sorry for late response.

socratis wrote:Take a look at a post from 'fth0' regarding this. The solution is to issue the following command, with the VMs completely shut down:

• 
  VBoxManage modifyvm "FreeBSD #1" --spec-ctrl on
  VBoxManage modifyvm "FreeBSD #2" --spec-ctrl on
  VBoxManage modifyvm "CentOS #1" --spec-ctrl on

I issued these commands and now all 3 VMs boot successfully. So now the problem is solved. But please let me ask some more question.

Q1. At first I thought there are 2 possible source of this problem.

• Change of H/W itself causes this problem.
• As a result of H/W change some inconsistency happens between real H/W spec and information about H/W stored in host OS. And the inconsistency causes this problem.

But after reading fth0's post I understand the former is the case and therefore the problem still happens even if I do clean install of host OS. Is it right?

Q2. Each time I create new FreeBSD VM I need to issue this command to it. Are there any way to configure VirtualBox so this command is automatically issued when new VM is created?

Best Regards.

Yasuhiro wrote:So now the problem is solved

Great. Marking the thread as such...

The Speculative execution is a nice concept, but it had some security issues. The vendors of hardware/software issued patches to prevent that. Maybe your new hardware/software doesn't provide that. The commands that you issued make sure that it does on the Guest.

Yasuhiro wrote:Each time I create new FreeBSD VM I need to issue this command to it.

Correct.

Yasuhiro wrote:Are there any way to configure VirtualBox so this command is automatically issued when new VM is created?

No, not yet.

fth0 wrote:The guest tries to read the SPEC_CTRL MSR (0x48), probably without checking for its existence.

I'll start talking to myself and explain my speculation:

Following the Intel Software Developer Manuals, an implementation should check for the existence of Machine Specific Registers (MSR) before reading from them or writing to them. In your case, it has to check for the existence of the SPEC_CTRL MSR (in the CPUID leaves, see CPUID dump in a VBox.log file if you're curious). So much for the theory.

In practice, an implementation can recognize the CPU from the CPUID leaves and (maybe thinks to) "know"[*] that the CPU has the SPEC_CTRL MSR, and therefore does not check for its existence. Now comes VirtualBox and tells the guest OS in the CPUID leaves that this CPU does not have the MSR, the implementation ignores this information and accesses the MSR -> Guru meditation.

[*] The SPEC_CTRL MSR is available in most newer Intel CPUs.

fth0 wrote:I'll start talking to myself

Hey! Welcome to the club! Application forms will be arriving shortly in the mail!

fth0 wrote:it has to check for the existence of the SPEC_CTRL MSR (in the CPUID leaves, see CPUID dump in a VBox.log file if you're curious).

Count me in the curious team. Besides getting a Guru, where exactly do you see that MSR information?

I take it that you mean this section:

00:00:08.067268 ************************* CPUID dump ************************
00:00:08.067277          Raw Standard CPUID Leaves
00:00:08.067277      Leaf/sub-leaf  eax      ebx      ecx      edx

... which BTW is all "Greek" to me.

socratis wrote:Count me in the curious team.

Ok, I'll give you a short introduction:

The CPUID dump section of the VBox.log file contains some hexdumps and some interpretations thereof. The hexdump lines are prefixed with Gst and Hst. CPUID is an Intel CPU instruction[*] that can be used to question the CPU about many of its capabilities. When using the CPUID instruction, the host OS (and applications running inside) gets the values shown in the Hst lines from the real CPU, whereas the guest OS (and applications running inside) is given the values shown in the Gst lines by VirtualBox. This way, VirtualBox decides what the guest OS sees, including combinations of capabilities that don't exist in real life CPUs, especially regarding the Spectre/Meltdown related capabilities.

socratis wrote:Besides getting a Guru, where exactly do you see that MSR information?

Here are the relevant lines from one of my own VBox.log files:

VBox.log file wrote:

00:00:01.439740 Features
00:00:01.439740   Mnemonic - Description                                  = guest (host)
00:00:01.439748   MSR - Model Specific Registers                          = 1 (1)
00:00:01.439822   IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB  = 0 (1)

The guest OS using the CPUID instruction would learn that the SPEC_CTRL MSR is not available.

If you have more specific questions, please don't hesitate to ask.

===

[*]To give you the reference and a sense of scale:

The reference information can be found in the Intel 64 and IA-32 Architectures Software Developer Manuals, which contain several thousand pages of documentation. The CPUID command is described in about 40 pages, the MSRs are described in about 400 pages (and those numbers are no spelling mistake ).