[vbox-dev] How does VirtualBox catch privileged instructions?
Sander van Leeuwen
Sander.Vanleeuwen at Sun.COM
Tue Apr 27 02:50:06 PDT 2010
On 23-4-2010 8:59, Andrei DAMIAN-FEKETE wrote:
> I've searched but I couldn't find yet a concrete answer to the question of how does VirtualBox catch privileged instructions (without hardware virtualized support)?
> For example when executing raw in/out instructions in guest user mode the instructions would usually generate a General Protection exception. Does VirtualBox patch the #GP vector in Windows host's IDT to trap it? Does VirtualBox receive an information from Windows host after the Microsoft's original kernel interrupt executed? (seems unlikely).
VirtualBox keeps a shadow IDT to make sure we catch all traps first. We
don't patch the guest's IDT at all; it's simply not active.
> If VirtualBox patches IDT how does it do it on Windows 64 bit which runs PatchGuard and which should stop non Microsoft drivers modifying IDT? (it's a must to have support from hardware virtualization?)
64 bits guests require VT-x or AMD-V. In that mode we do not replace the
IDT as there's another mechanism to intercept faults.
> I've run VMWare and VirtualBox at the same time on a Windows XP SP3, 32 bit host. I've checked the address of IDT from user mode with sidt instruction (in a loop to see if it changes) and it was like this:
> VMWare: FFC18000 (if acceleration was disabled sidt was emulated and it showed 8003F400)
> VirtualBox: F8808190 (with disabled VT-x/AMD-V)
> real machine: 8003F400 / BAB3C590 (CPU with two cores).
> From what I understand sidt can't be caught so the values should be normally unmodified by VMM (unless patched) and if there was an exception the CPU would automatically and directly jump to the address stored in IDT.
> But I can't seem to be able to read memory at F8808190 or FFC18000 (but I can read the IDT tables from 8003F400 / BAB3C590 and the addresses in them seem to point to ntkrnlpa.exe).
Correct, sidt can give you VirtualBox's IDT if the instruction isn't
patched. That memory is read-only from the guest's point of view even
though the guest's kernel is not (completely) aware of the region there.
Kind regards / Mit freundlichen Gruessen / Met vriendelijke groet
Sun Microsystems GmbH Sander van Leeuwen
Werkstrasse 24 Senior Staff Engineer, VirtualBox
71384 Weinstadt, Germany mailto:Sander.Vanleeuwen at sun.com
Sitz der Gesellschaft: Sun Microsystems GmbH,
Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder,
Wolfgang Engels, Dr. Roland Boehmer
Vorsitzender des Aufsichtsrates: Martin Haering
More information about the vbox-dev