[Hikikomori]

It could if the hardware allowed such separation, but the x86 platform doesn't do anything close to that and allows reading memory of other processes in so many different ways in both userspace and kernel. Not to forget hardware being able to read memory via DMA that many use now.

[lloeki]

- Have a thin hypervisor kernel

- Have the user-facing OS be a VM managed by that hypervisor

- Have the game process run under a second sibling VM

The hypervisor can then mediate hardware access and guarantee nothing from VM A can access VM B nor the other way around.

IIRC WSL2 enables such a mode, both the Windows OS the user sees and the Linux VM run under Hyper-V as siblings VMs.

And Xbox One and up do EXACTLY the above: each game runs in its dedicated VM (I presume that's what "trivially" enables Quick Switch/Resume via pausing/shapshotting the VM) and apps run in another.

Tangent: I somewhat wish MS would allow WSL2 on Xbox.

[ElectricalUnion]

Without hardware support, once the attacker gets to the hypervisor, you can't trust the hypervisor, or the "guarantees" that such tainted hypervisor provides to be upheld.

You need hardware support for confidential computing (for example, AMD SEV) to be able to trust that the hypervisor can't just read/write all over the VM RAM.

[lloeki]

Sure, security comes in layers. A trusted platform boot chain can validate the hypervisor much easily than a whole hard disk, and existing x86 instructions can do the rest. The attack surface is also quite a lot smaller. It's already miles better than unfettered access from the very same OS and anticheats being privacy-invasive rootkits.

Hardware support for confidential computing is cherry on the cake, but in this scenario the user is not trying to defend themselves against an attacker, the game is, from the user a.k.a the cheater.