21–30 of 294 posts
Restricting performance.now()'s resolution to 1ms is really bad news :( Once the other mitigations are in place, will the webkit team consider increasing the resolution again? Can we get a Developer menu or Web Inspector option to temporarily enable the old resolution again?
The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.
Earlier quoted context omitted.
Apple does this sometimes for macOS. It's probably because it's an application update, not an OS update (so OS patch version does not change), and doesn't require a reboot.
This doesn’t explain why they kept Safari at the same version number.
> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't t…
As for relying on users ability to determine what code is safe to download... It's not like users can be relied on to do the right thing all the time even without javascript. People respond to phishing attacks, download executables sent to their email, reuse passwords... I think a sandbox is a better solution than relying on users to understand what code is trustworthy and what isn't.
With current CPU design there is only so much that can be done, but the architectural fix seems obvious to me, one that doesn't give up the performance benefits of speculative execution and branch prediction. The data in caches, the TLB, and the state tracked by branch prediction must be segregated by the protected mode bit. That isn't sufficient so solve all the problems, but seems like it solves a number of them.
Earlier quoted context omitted.
You are removing branches, and adding slightly less clear code to do it. If this resulted in faster or cleaner code you would already be doing it. So the OP’s point holds: if these security holes are fixed at the CPU level, there will still be a generation of software compiled with these mitigation’s in and no way for a user on a newer CPU to disable them. EDIT: I just wanted to clarify here that I did not mean “all…
We are not removing branches. To fix this in hardware without software changes you would have to disable branch prediction. That would perform worse than what we are doing.
It is a really cool piece of engineering but we can still be sad we have to implement it.
(On the hardware side I was assuming sommeone clever at Intel will come up with some security non Perf killing change to make branches trustable again).
Earlier quoted context omitted.
You are removing branches, and adding slightly less clear code to do it. If this resulted in faster or cleaner code you would already be doing it. So the OP’s point holds: if these security holes are fixed at the CPU level, there will still be a generation of software compiled with these mitigation’s in and no way for a user on a newer CPU to disable them. EDIT: I just wanted to clarify here that I did not mean “all…
The mitigations are largely in code produced by the JIT. It's not hard to patch the JIT's codgen to back this out (perhaps even based on current CPU) if it becomes unnecessary. It would be nice if CPU architectures never had this fundamental vulnerability, but they do. So this seems like the best response for the reality we actually live in.
> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't t…
Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something…
While I am mostly a pessimist, this is one place where I harbor a tiny sliver of optimism. Once users recognize that something is awful, and have the means to get rid of it, they eventually do so. Client side Java and Flash are dead, because everyday users figured out that they sucked, and were given the option not to use them. We're getting close to a situation where average people recognize that millisecond auctions to run arbitrary code on their machines are a bad idea, and those people also have the tools to say "no." Hope springs internal...
> WebKit is affected because in order to render modern web sites, any web JavaScript engine must allow untrusted JavaScript code to run on the user’s processor... WebKit is affected by both issues because WebKit allows untrusted code to run on users’ processors. There's the elephant in the room, though this article doesn't go far enough. Trust isn't binary. It's not that the code isn't formally verified, or doesn't t…
Unfortunately the genie is out of the bottle already. The web by and large requires javascript, and it's not likely to change anytime soon. So we are stuck with the situation where the defenders (the hardware and software designers) have to be correct 100% of the time on a platform that is constantly changing. The attackers only need to be right once. Maybe someday everything will just be streaming video or something…
This fatalist stance is childish, and dangerous. As long as there are people working to make things better, things do improve.
Sure, if you make sure that one small website works without JavaScript then that doesn't change the world. I hear a similiar argument when I explain why I don't eat meat; I'm told that animals will be killed anyways. But if I don't eat meat, then less will be killed. How many less? I can't specify the number, but I don't power-hungrily demand my own decision can magically change the world completely over night, and give up when I realize it doesn't.
Still, each and everyones has an influence. It's about doing what's right. And even if you are the only one doing the right thing, things will be a bit better for your actions. But in fact the situation isn't that bad, and one isn't alone.
> It's not like users can be relied on to do the right thing all the time anyway.
So, if you aren't sure you locked the front door of your house, then it also doesn't matter if you left the door to the garden open? Clearly it does matter!
This fatalism deems us into inaction and into accepting the status quo even if we know it's bad.
Earlier quoted context omitted.
We are not removing branches. To fix this in hardware without software changes you would have to disable branch prediction. That would perform worse than what we are doing.
Sorry maybe I missed something but you had some really cool techniques to avoid using branches to do things like array length checks and type checks? So you replaced an if branch with a new, potentially slower, and harder to understand concept. I was not trying to imply you removed all branches. It is a really cool piece of engineering but we can still be sad we have to implement it. (On the hardware side I was assum…
Similarly, where we use pointer poisoning, it is in addition to some other security check, which is almost always a branch.