> Seen that way, the defense has to be against remote code execution, not against cross-process memory reads. This doesn't always look like what it is. You hav

> Seen that way, the defense has to be against remote code execution, not against cross-process memory reads. This doesn't always look like what it is. You have games that allow e.g. custom levels with map editors, and then the users download the level from the other users and execute whatever code is part of making the level work. This could be exploitable for timing even if it's in a game-specific language. Or isn't even intentionally "code" but still an attacker can use it as a Weird Machine to the same effect. Putting it on the game developers to make sure none of that is possible is never going to work. What might work without needing physically separate hardware is to assign dedicated cores to highly performance sensitive programs, with the mitigations disabled on those cores because they're no longer shared. The cost is you would have to leave at least one core for everything else, but that feels like a good trade off. It may even be possible to use the shared core(s) for the game (with lower scheduling priority) even though the mitigations are still turned on for shared core(s).