Basically a revert to the security model of Windows XP. We should assume access to execute any code means the same security level as having physical access to a machine (I.e. full machine ownership)?
That would be an incredible disaster, especially if you count "inside a VM" as "on the same machine". Even more so if you count Javascript as "code". And I think it's an overreaction.
I think it is too. Perhaps a better question is: should we really be using the same kind of threat models and mitigation strategies for my gaming machine where I'm alone, and another extreme: A machine running virtual machines for a cloud provider?
For the latter case, issuing microcode/OS fixes or recompiling apps to be more secure but losing 10% performance is probably a worthwhile thing. For the single user machine it's absolutely unacceptable. A gamer would much rather have the XP security model than lose 10% performance in even some rare scenarios due to (for example) extra cache flushes designed to mitigate timing attacks! I'd at least want the option.
So while I don't think that everything we held to be true about computer security is about to go out the window, I almost hope that the future will hold different security for different scenarios. Just because I run the same OS on the same CPU doesn't mean I necessarily need the same security.
And unless you have multiple CPUs or can ensure the cores do not interact in unexpected ways, you essentially have to accept the cost, remain vulnerable (and eat the worms) or replace the hardware with something fixed.
.. but you probably still don't want your machine to be remotely exploitable by other players. And gaming has the interesting security issue of "anti-cheat", where it's useful if players can prove they're not leaking information from the game process on their own machine. And lots of people will use the same machine to play games and do online banking.
Perhaps the way out is more than one "computer" on the same board with different security models. There's already bits of this with TPMs and ILO systems, but the manufacturers care more about keeping them proprietary than making them usable.
Right. These kind of vulnerabilities are more along the lines of IF an attacker is able to do arbitrary code execution in my first person shooter, by giving it some crafted netcode packages in a multiplayer game - could he then also read my credit card data from my web browser process through a side channel?
And I'm willing to say that - yes - I accept that he can, or at least I'd rather that be possible than sacrifice performance. I realize that any process I run in windows is vulnerable to spying by any other process. Seen that way, the defense has to be against remote code execution, not against cross-process memory reads.
One example of this cross process weakness in windows: once he runs arbitrary code he can just take a screenshot of any other program anyway, including the window with my credit card details in it!
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).
It seems they are complex enough that the answer may be "never", at least for some high risk scenarios.
on kabylake & skylake this has been the recommendation anyway https://lists.debian.org/debian-devel/2017/06/msg00308.html
It is time to rethinking the engineering methodologies we use in the electronics/informatics field.
http://3.bp.blogspot.com/-OyjQUpLowmg/Udz1_NxqNLI/AAAAAAAABV...
* https://www.mail-archive.com/source-changes@openbsd.org/msg9... (https://news.ycombinator.com/item?id=17350278)
XP, specially after SP2 was as safe as NT, if users bother to actually make use of administrator/user separation roles.