Comment by HALtheWise

I did a pretty deep dive into this recently, although haven't yet started any implementation work. As far as I can tell, the best strategy that preserves Linux's open-source and user-empowering ideals as much as possible:

- The game obviously needs to run as root, at least until large amounts of this stuff gets upstreamed into the kernel.

- We're going to be leaving the kernel and boot as untrusted, but injecting a hypervisor underneath the running kernel that is responsible for protecting most pages of game memory. This allows users to still run whatever kernel they want.

- The hypervisor sets up two sets of page tables, one that's only active when the game's thread is running and in userspace, one that hides protected pages and is active when the kernel or other threads are running. Note that game code itself needs to get decrypted into protected ram.

- The TPM of the system gets involved when we jump into the hypervisor to attest that the hypervisor is actually running, and the hypervisor then provides attestations to userspace that certain memory regions are protected from kernel or other thread access.

- Any syscalls will fail if they require the kernel to read or write pages that are protected. The game needs to allocate data that should be shared with the kernel into non-protected pages.

- When the game is closed, we can remove the hypervisor and Linux will be back to bare metal operation. This should be unobservable to the rest of the system.

This architecture preserves the ability of users to run arbitrary kernel modules, but does mean a hypothetical attacker can observe data that passes through the kernel (like draw calls/pixels). It's likely that a more complete implementation would also want some way for the hypervisor to attest to the accuracy of keyboard/mouse input and interface with iommu configuration like Windows KAC does.