If I spin up an OS in a VM, can Microsoft still collect and track data from the guest OS? I'm just wondering if Windows 10 collects that much data or not.
Just FYI: no, I'm not a nutter that's obsessed with Windows 10 data collection, I was just looking at VM's and was wondering how this works.
They technically can, but they only do so under certain circumstances.
A malicious hypervisor can tamper with the guest at will. A virtualized guest allows the hypervisor to trap certain instructions, deferring action to the hypervisor itself. If you spun up a guest operating system on a compromised Windows machine, it would be able to compromise the guest. From the perspective of the guest, the hypervisor runs at what has been nicknamed ring -1. The implication is that it is even lower and more privileged than ring 0, which is true (though it is not implemented as an actual protection ring, but the effect is roughly the same). A technology called SGX on newer processors can run certain aspects of a virtual machine in such a way that the hypervisor cannot tamper with it, but I do not believe there are any implementations that are sufficient.
So Windows absolutely has this ability, but does Windows actually do this collecting by default? Sort of. While they will not tamper with your guest and upload a bunch of private details relating to it, crash dumps relating to virtualization may be uploaded to Microsoft, and this detailed information may contain sensitive data from the running guest. You can avoid this by turning off error reporting.
Warning! Technical details ahead!
I explain how virtualization works in an answer to another question. It might be a good idea to read that answer to understand exactly what a hypervisor can do to the guest and what it cannot. A simplified but easy to understand view is provided in the slides for a lecture paper on virtualization:
In practice, most of the time the hypervisor simply lets the guest run on the real CPU and memory, not knowing what the guest is doing. [...] If the guest is executing an "interesting" assembly instruction then the hardware traps it, and the hypervisor emulates the instruction carefully.
Some instructions can be configured to trap. Others trap unconditionally, such as out which is used to communicate with other hardware and do things like shut the system down. Others still, like mov, don't normally trap and will run without the host or hypervisor being able to influence them directly. When an instruction traps, control is temporarily returned to the hypervisor. It can choose to deny the instruction, run the instruction directly, or emulate it. From the perspective of the guest, an instruction that gets trapped simply takes a little longer to retire. From the perspective of the host, the VM is just a very slow instruction that only returns when the code in the guest is trapped and the hypervisor needs to make an executive decision, after which the VM resumes.
