Hacker News new | ask | show | jobs
by metta2uall 380 days ago
I have a lot of admiration for the WSL1-style approaches & hope they bear fruit. The major problem with WSL2 & Android VMs is that they're a pain in an already virtualised environment - there's then a need for nested virtualisation.
2 comments

On a recent computer with a recent Windows installation what you think is bare-metal Windows is actually a (high-privilege) VM running under Hyper-V.
This is absolutely irrelevant to the above comment because there is no nested virtualization involved: the "high-privilege" VM will spawn other VMs as siblings of itself (in the root Hyper-V instance), not as nested VMs.
The parent partition is not considered a VM, nor does the implementation of VBS make the "parent partition" (with just VBS, it isn't) a VM.

https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...

The parent partition has full access to hardware and child partitions (VMs). The hardware is not virtualized to the parent.

What source can you point to that backs up this claim? Also, is this for Windows Server only or for desktop versions also?
Even before the virtualization-based security feature was introduced this has been the Hyper-V architecture, on server and client SKUs. The management OS is referred to as the "parent partition" or "root partition," and it runs on top of the hypervisor: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
It's various pieces are called Virtualization Based Security/Core Isolation/Hypervisor-Protected Code Integrity

> Virtualization-based security, or VBS, uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised.

> While VBS greatly improves platform security, VBS also changes the trust boundaries in a Windows PC. With VBS, the Windows hypervisor controls many aspects of the underlying hardware that provide the basis for the VBS secure environment. The hypervisor must assume the Windows kernel could become compromised by malicious code, and so must protect key system resources from being manipulated from code running in kernel mode in a manner that could compromise security assets.

https://learn.microsoft.com/en-us/windows-hardware/design/de...

https://learn.microsoft.com/en-us/windows-hardware/design/de...

Architecture Image: https://www.microsoft.com/en-us/security/blog/wp-content/upl...

To add more to the context, VBS is also why Windows 11 requires 8th Gen CPUs or newer, because only those have added working hardware VBS.
The link about VBS above says it requires

> Intel VT-X2 with Extended Page Tables (EPT)

As far as I know, this doesn't limit CPUs to 8th Gen and newer. Neither does VT-x and the other requirements.

Furthermore, there are supported ways of disabling VBS entirely so the gimped version of Windows 11 that doesn't use VBS you'd get for installing it on older hardware wouldn't be that different from an install you'd disable VBS on to get 15% better performance in video games.

Yes if you enable Hyper-V the main Windows installation is running under a hypervisor, but it's running with nearly complete access to the physical hardware.
Is nested virtualisation still a problem on Windows? Intel and AMD have supported it for so long I don't think I still own hardware that lacks it.

It's a pain when renting a VPS sometimes, but on Windows I don't think that's a common problem.

It's not a problem for Windows, it's a problem for AWS: only metal instances support nested virtualization. To this very day you can't use WSL2 on most EC2 instances.

It's also a problem for Microsoft's new ARM64-based Surface devices: Snapdragon X doesn't support nested virtualization, even though Windows does.

> It's also a problem for Microsoft's new ARM64-based Surface devices: Snapdragon X doesn't support nested virtualization, even though Windows does.

Snapdragon X does support nested virtualisation - it's Windows that doesn't support it on arm64 yet

Thank you for this correction. That gives me some hope, then, that maybe we'll get it fixed. I didn't realize this limitation before I bought the device and had to find out when I got the Hyper-V error message :/
iirc they took quite a while to enable it on AMD after Intel, so maybe the wait will be quite significant...
Why would you?

If I have access to AWS, I will be spinning up Linux VMs for GNU/Linux workloads.

AWS has a service providing license-included Visual Studio development VMs for enterprises. These run on EC2 but the users don't have access to AWS services in that sense. These VMs can't run WSL2 because of the lack of nested virtualization. This ends up being fairly painful for Windows-based development; WSL is used for lots of things, integrated with our Windows environment, and WSL1 is much slower.
I guess it is a business decision then, I never been in such situation, it was always rather easy to have a few EC2 GNU/Linux VMs around.
It's not really conducive to use a separate machine for these development use cases; WSL is integrated to the Windows side more tightly than a separate VM is. For instance, you can launch Windows EXEs directly from the Linux side as if they were native, so you can have a single script that runs tools from both sides natively, on the same computer, without remoting or SSH or anything like that. This all works with WSL1 too (which doesn't use virtualization), it's just a lot slower.
Hyper-V has supported nested virtualization since Server 2016/Win 10. It is also supported to run WSLv2 in a nested VM.