If you use different passwords, you must believe they are in different trust zones, and the usual time sharing methods won't work, in light of this and many other attacks. You will need separate CPUs as suggested by rayiner.
You can run trusted code on one processor and untrusted on another. The untrusted processor must not perform speculative execution. It'd be slow but should solve the presented conundrum.
Unfortunately, being slow is just not acceptable in a decent portion of scenarios. Web developers won't start writing 5x faster sites, and cloud providers won't like needing 5x more hardware to serve the same amount of virtual CPU performance. (5x being my random guess of the performance decrease from losing speculative execution & co; it'd likely be even worse, especially combined with the fact that manufacturers would have to design a completely new chip)
Their point is untrusted code can still have private info (I don't want a random website to be able to steal my private key or my info like credit cards or password in other tabs), so you need a new core for each website, which is obviously impractical.
My point is that if you disable speculation on the insecure core then the websites can share without this class of exploit being a risk factor. There my be other vectors for accessing the data of colocated processes.
They aren’t in different trust zones, because there’s nothing to trust in either of those. The reason for using different passwords is to minimize the losses when they leak.
They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.
That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.
(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)
I’m not entering credit card info though. And even if I did, it’s not very security-sensitive - in the worst case the bank will give me back my money stolen from the card.
If you truly never enter credit card info on the web, or truly have zero expectation that other tabs shouldn't be able to spy on that credit card info when you do, then frankly you're so outside the range of normal people's expectations and behaviours that I don't think basing security architecture around what you do or don't do makes any sense whatsoever.
