You should mention in your article that you describe only Intel processors, not AMD64 processors.
Intel processors (VT-x) use VMCALL, VMLAUNCH, VMRESUME, VMXOFF, and VMXON.
AMD64 processors use VMLOAD, VMMCALL, VMRUN, and VMSAVE in a similar mechanism called a Secure Virtual Machine (SVM). See chapter 15, Secure Virtual Machine, in the AMD64 Architecture Programmer’s Manual Volume 2: System Programming.
thanks for your article. It's written quite well understandable but as I see that I will need learn more about paging first - unfortunately cannot be avoided
You mention that hypervisor is quite complex because need of a lot drivers etc, but...
My question is that if it is possible to code a tiny hypervisor that will pass most of events to real hardware and let existing BIOS to handle it instead of complex drivers. So that the guest will run mostly same as not under hypervisor. Except I would want to trap some specific IO access and emulate it. This shouldn't be so hard. I don't want to isolate guest neither I don't want to run multiple guests. I mean DOS in RM/PM/V86 as guest not any modern complex OS. I expect that I need my CPU supports unrestricted guest to do that. I'm aware that in pass-through mode my VMM code can be overwritten by guest but with DOS I could minimize this by instructing XMS manager to limit maximum available memory to leave some free space at the top. Then any program shouldn't touch beyond that limit (of course I cannot prevent direct intentional access but normal program shouldn't do that).
Thx for reply, Martin
Yes, it isn't that hard, as long as you can protect yourself from overwriting. You don't necessarily need unrestricted guest, for you can also run DOS in a protected mode V86 (that's what EMM386.EXE does).
The real question is *why* you want to virtualize DOS. I 'm currently trying to virtualize Windows in a pass-through system.
>The real question is *why* you want to virtualize DOS. I 'm currently trying to virtualize Windows in a pass-through system.
I'm a fan of DOS old sw, games, demos, etc. I was just thinking (a dream) if the virtualization could be used to emulate SoundBlaster (using HDA or another modern soundcard that is not compatible). Dosbox is still slow and commercial VM SW like VM Ware don't emulate SB/don't support DOS. So my idea would be thin hypervisor that will pass any HW/BIOS access to real HW except the specific IO access for SB. Also I think it would be nice to use VMM as a RM/PM debugger that will work transparently and I could trigger it by interested IO access or memory access. I read about hyperdbg for windows but when I tried it failed to install/launch it's driver and didn't work. But I mean something simple as debug for dos but with power of hypervisor.
And last, I read verious articles about how hypervisor can be abused to run user OS for keylogging, etc. bad things. Attacker simply elevate privileges with some exploit and then install it's hypervisor - all under running OS without letting user know what's happening. How much complex have such hypervior be to be able tu run windows? I doubt that it use tens of megabyte drivers like vmware, it must be quite thin to hide in system. Even some of that can hide in bootsector (+ few spare sectors) or permanently in firmware...
My point is to create a hardware Windows debugger which would function like normal COM or NET kernel debugging, but from an inside system.
I 've successfully worked on updating virtdbg in order to be installable in Windows and I successfully put Windows into virtualization by simply creating a pass-through of the entire memory and CPU state.
The problem is what to do next. My point was to be able to save/restore the memory so, in case of a driver crash, my driver would be able to restore the CPU to the state it was before the crash. However this requires that I propagate all stuff from the real CPU to the virtual CPU and cancelling out everything in the real cpu, perhaps switching it back to real mode or, at least, remove paging so I can read physical memory without mapping.
This means that I 'd have to rely on BIOS for disk i/o access (because I won't anymore have windows API available), which means that I have to (at the very least) create a NTFS driver.
Oddly, it was an interest for me for a good, long time and squeaked past the topic about a week ago. Dismissed the subject due to time versus complexity level, but here I am. Nice delivery and props for picking a topic that concerns many, but gets far too little face time.