0

I know So-called Type2 Hypervisor(such as VMWare Workstation, VirtualBox) is implemented as kernel module. And VM-instance is host OS process.

Assume the following situation.(I understand this is strange but for simplicity)

  • A Machine has one CPU.
  • Host OS is Windows that has two process, calc.exe and VM-instance(booting Linux).
  • calc.exe has some sensitive instruction.

I don't understand that whether Hypervisor traps sensitive instructions or not, while running calc.exe on CPU.

I have two ideas.

i) Hypervisor traps sensitive instructions from calc.exe. Hypervisor identifies calc.exe or VM-instance process. And if necessary Hypervisor emulates it that executed from VM-instance process.

ii) Hypervisor doesn't execute vmresume when VM-EXIT caused by interrupt for context switch. In other words, CPU is "VMX ROOT MODE" while executes calc.exe. Therefore Hypervisor doesn't work.

In case of ii), How does Hypervisor execute vmresume when VM-instance process is reassigned to CPU?

Thank you.

Imagine Context Switch

nadegata
  • 3
  • 2

1 Answers1

0

Being "sensitive" means an instruction could tell the difference between running inside a guest VM or not. (Or could affect state outside the guest VM). calc.exe isn't running inside a guest VM so it doesn't matter what it does.

calc.exe is basically part of the hypervisor. It's up to normal OS mechanisms to stop a user-space process from messing up other processes (including the guest VM), i.e. not letting them disable interrupts or overwrite the memory of other processes.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Thank you for your answer. I understood calc.exe is executed on VMX ROOT MODE. But I don't understand when context switching from calc.exe to VM-instance process, how does hypervisor execute vmresume. I think that if CPU remains VMX ROOT MODE, hypervisor can't trap context switch from calc.exe to VM-isntance. Furthermore it can't trap sensitive instructions from VM-instance. Could you tell me that, please ? – nadegata Jul 28 '21 at 11:59
  • @nadegata: The host kernel basically *is* the hypervisor. Nothing needs to be trapped. calc.exe isn't in a guest VM, it's running on directly on the hardware (although unprivileged). e.g. its page tables are only the normal 4-level x86-64 page tables, with the result of virt->phys translation being real physical CPU addresses, no EPT needed. – Peter Cordes Jul 28 '21 at 12:30
  • While Host OS executing VM-instance process, CPU must be VMX NON ROOT MODE to trap sensitive instruction. But when Host OS does context switch from calc.exe to VM, I think Hypervisor can't revert CPU to VMX ROOT MODE becase it can't trap Host(Windows) Context Switch. If above is correct, CPU executes VM-instance on VMX ROOT MODE unless Hypervisor executes vmresume. (this is not good) I'm curious to know that how does hypervisor revert CPU to NON ROOT MODE. (I added image of context switch to text body. My question is based on this. Is this image incorrect ?) – nadegata Jul 28 '21 at 16:44
  • @nadegata: A context switch happens in kernel space, to the "hypervisor" process. (At least I assume Windows works that way). It can `vmresume` to return execution into the VM guest if it wants to. If you really want to know the details, I'd recommend looking at open-source implementations like KVM under Linux. Your image leaves out the kernel itself, giving the impression that nothing executes between the VM guest and another user-space process like calc.exe. – Peter Cordes Jul 28 '21 at 21:14
  • Thakns to your advice "A context switch happens in kernel space, to the "hypervisor" process.", I understood it. Maybe I had lack of understanding toward context switch and mechanism of managing of VM process . I'll try to read Hypervisor. I appreciate your polite explanation. – nadegata Jul 29 '21 at 11:01