> But since WSL 2 it does use a VM.

As a related sidenote: Try doing an apt install metasploit inside a "VM" while an antivirus is running on the host.

You'll soon realize that the "VM" will be bricked by quarantine actions on the NTFS based filesystem, which kind of defeats the reason of the V in VM.

I fear once more people realize this, there'll be NTFS stream based "hidden" malware and other filesystem rights abusing tools everywhere all over again.

That’s because the VM has hooks into the host filesystem though, isn’t it? Does it still happen if the VM is fully isolated from host resources (files, ports, devices)?

Wouldn't simply activating file-level encryption in the Linux subsystem be enough to throw off Windows-based AV scanners?

I didn't test whether or not LUKS or similar filesystem level encryptions are transparently mapped to the Windows kernel.

Might be a good way to avoid this behavior. The default (from the Windows Store) Ubuntu based VM however doesn't use filesystem level encryption, and every folder or file inside the "VM" is available somewhere buried in the Roaming folders.

Yeah, you'd have to install LUKS or eCryptfs or something, but I think it would be worth a try. I expect Windows would only see the encrypted files then.

When installing WSL you can still choose if you want to use WLS 1 or WSL 2, and you can switch between them. If you keep your files not in the WSL filesystem, WSL 1 is still the recommended choice because of the lower overhead for file access.

Plus WLS 1 is marginally easier to install because you don't have to enable Hyper-V

You also don't get "vmmem" process that eats memory and doesn't give it back

I recently updated my visual studio code development environment and it depends on WSL 2 now. It seems to be that this is the direction MS is heading.