jmtella wrote:
Lots ofurban legendandmanyinternetpagesmisspelledonvirtualizationandhypervisormode.
Basicallythere are 4ringsorexecutionmodes. An operating systemruns inring0. User programsinring 3. Invery special caseswindowsusesring 1. Ring0isthe only one whohasaccess to the hardwareand control over theupper rings. Communication betweenringsis only possible throughtaskgates, which are definedfrom the ring0. An error inring0isblue screen.Errorupper ringsis controlled by thering0.
While this is essentially correct, the privilege rings are largely irrelevant to this discussion.
Thehardware-level virtualizationconsistsin creatinga ring-1which thereforehas control overtheupper ringsincludingring 0hostsystem.
TheBaremetalhypervisorsrunningon said ringandthus hascontrol over thehostsystem. HyperVdriverrunning onsaid ring.
There is no such thing as ring -1. The hypervisor runs in ring 0. The guest kernel also runs in ring 0. The difference is that the hypervisor runs in root mode (or host mode), and the guest runs in non-root mode (or guest mode). Guest/host mode is orthogonal to privilege level.
I work insecurityand I have seenproof of conceptviruscapable of runninginring-1 withhypervloaded.Thereforeno possibilityof load at-1ring. Thereforecoexiston the same levelHyperV.
Again, there is no such thing as ring -1. I assume you mean you have seen a virus capable of running in root mode (or host mode) with Hyper-V loaded. This could be done if the virus actually modifies the Hyper-V code so that it can obtain control at a VM-exit from the Hyper-V guest. However, that would not be a viable approach for a commercial product. Microsoft would certainly object to such an implementation.
If this virus can run in host mode alongside Hyper-V without modification to the Hyper-V code, I would like to know more about it.