Why does PF_VIRT_FIRMWARE_ENABLED return false even when virtualization is enabled in the firmware?
The IsProcessorFeaturePresent function has a processor feature called PF_VIRT_FIRMWARE_ENABLED. A customer enabled virtualization in their firmware, but calling IsProcessorFeaturePresent with that feature still returned FALSE. Why is this function lying?
It’s not lying.
Even if you enable virtualization in firmware, it may not actually be available. If the operating system is running inside a virtual machine, then it cannot access the virtualization extensions because the virtualization host is using them. Checking for PF_VIRT_FIRMWARE_ENABLED will say “No virtual extensions for you.”
Even if you think that you’re not running inside a virtual machine, you could be. If Hyper-V is enabled, then the root operating system is not actually in charge. The root operating system is running inside its own virtual machine, under the control of the hypervisor.
And remember that features like Virtualization Based Security and and Windows Defender Application Guard are security features which secretly use Hyper-V to create virtual machines to isolate untrusted code into their own containers.
Bonus chatter: I dimly recall that the IBM 360 supported self-virtualization, so you could have the host hypervisor create a virtual machine, and in the virtual machine, the operating system could itself act as a hypervisor for its own little universe of virtual machines. It’s virtual machine turtles all the way down!
Light
Dark
3 comments
360 virtualization: Melinda Varian documented some of this history. The following happened circa 1970:
When [Alain] Auroux started, Cambridge was running a 360/67, not a S/370, and that 67 was a production system, so he had to avoid destabilizing it. “Vanilla” CP-67 systems created System/360 virtual machines, but they did not virtualize the 360/67; that is, they did not allow a guest to create its own virtual storage. Auroux’s first step was to modify CP-67 to create virtual 360/67s, which used 4K pages and 1M segments. Once he had convinced the Cambridge Operations Manager to run that as the production system, he could then proceed to develop a CP-67 that virtualized the System/370 architecture.
The System/370 relocation architecture was different from the 360/67 architecture; it allowed both 2K and 4K pages and both 64K and 1M segments. So, Auroux modified his modified CP-67 to support 64K segments and the new System/370 instructions. He ran that system second-level, so he could run a virtual S/370 third-level. He developed a prototype “CP-370” in that third-level virtual machine. Then, to test this CP-370’s virtualization of System/370 virtual memory, he had to run it both third- and fourth-level, with a couple of CMS machines running fifth-level. He remembers doing much of his testing from home at night using an “old, slow, noisy teletype”.
re Bonus Chatter – im fairly sure that Hyper-V supports nested virtrualization on windows
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization
Yes, Since Windows 10 1607 / Server2016. However, it’s only one nesting level, unlike System/360.