Hacker News Reader

Comment by Reventlov | Hacker News Reader

I have been teaching computer related classes to uni students for some time. Most of them run Windows. Running a virtual machine often means accessing the UEFI to be sure they have virtualization extensions enabled. And many of them have shitty personal laptops, which means running a VM will really slow the "Linux" experience. Sharing files between the host and the guest is also sometimes tricky, and I don't want to force them to install another OS on their personal laptops. WSL is nice in that it allows them to have a bit of Linux world without being very intrusive, and runs better than virtual machines on many of their laptops.

I'm what is called a "vacataire", which means I'm also not in the position of asking the school IT departement to enable stuff on the computers for the classes…

View on HN

> Running a virtual machine often means accessing the UEFI to be sure they have virtualization extensions enabled.

Likewise for WSL2.

I hope modern computers with a capable processor are all shipped with virtualization enable at firmware level, because Hyper-V can be used for tons of things in recent Windows.

Enabling hardware virtualisation opens up a significant and deep attack surface. Considering the vanishingly small percentage of users which benefit from it, I hope it stays off by default.

Windows is moving to a model where Windows itself is run as a virtualized OS. I believe this is enabled by default in new installs.

So having a Linux VM in Hyper-V isn't opening up much new attack surface.

It's not enabled by default. Enabling Hyper-V still causes a battery/performance hit that is going to be hard to get rid of.

Virtualization-based security -- a lighter mode of Hyper-V sans real VMs -- is enabled by default on new installs on recent-enough hardware:

https://techcommunity.microsoft.com/t5/virtualization/virtua...

The link you posted only contains one device and it happens to be an ARM device. Seeing the impact it still has on battery life at least on x86, I really doubt they have enabled it by default. It was not enabled by default on x86 in 2020 at least.

That's just a blog post about the feature being deployed, of course it won't have many examples. Take any PC from the past few years and install Windows 10 x64 on it. It will have VBS enabled and hypervisors that do not support Windows Hypervisor Platform won't work. That's been my experience since at least 2017.

If you click through "capable hardware" to here[1], you'll see the list of requirements for VBS, including:

> Virtualization-based security (VBS) requires the Windows hypervisor, which is only supported on 64-bit IA processors with virtualization extensions, including Intel VT-X and AMD-v.

So it will never be the case on x86/IA32

1: https://docs.microsoft.com/en-us/windows-hardware/design/dev...

Well, I'm asking because my experience is exactly the opposite. I've installed Windows countless times on systems with all the requirements and HyperV is not enabled. The day it starts being enabled, I don't even want to imagine the number of support calls.

Do you have a reference to the increased power consumption that running a hypervisor causes? This thread is the first I've heard about it, and I would like to learn more.

No, and I also would like to find some academical test. Try it -- you can even dual boot hypervisor on/off. It's not a small effect. Around 1h extra one on "almost idle" scenarios.

First I hear of this. Source? Googling for this predictably returned unhelpful results.

In VBS environments, the normal NT kernel runs in a virtualized environment called VTL0, while the secure kernel runs in a more secure and isolated environment called VTL1.

https://www.microsoft.com/security/blog/2020/07/08/introduci...

https://docs.microsoft.com/en-us/windows-hardware/design/dev...

Erm, explain? What attack can you do with hardware virtualization enabled that you cannot otherwise do?

I've read[1] that it can make Meltdown/Spectre attacks possible and thought I'd seen many more reports and discussions about it, but seems I was mistaken.

[1] https://nvd.nist.gov/vuln/detail/CVE-2018-3646

Are there significant risks from running virtualization locally like this? If so, can you provide any links or elaborate a bit so I can follow up? Most of what I've seen on such vulnerabilities refer to server infrastructure.

Having searched through my browsing history and some web searches it seems you're right. I do wonder if the move to more virtualisation outside of the server world will open up additional vulnerabilities but it does look like that's where most of the trouble is at the moment.

In Windows, enabling virtualization actually reduces attack surface. E.g. it is used to protect against kernel-level malware:

https://www.techrepublic.com/article/how-virtualisation-is-c...

Yes quite correct. I know some anti-virus engines have been using it for behavioural analysis. I wonder if this will mean more exploits against anti-virus emerge, as with their unpacker routines.

Well, android simulators do use hardware virtualization. And there is actually many people use them outside of developments.

unning a virtual machine often means accessing the UEFI to be sure they have virtualization extensions enabled

Note that this benefit applies to the deprecated WSL 1 only, WSL2 actually runs a VM underneath so it requires the same hoops that a VM would require.

Reply on news.ycombinator.com