11–20 of 294 posts
Isn't Intel and AMD shipping new fence instructions that prevent speculative execution from progressing beyond a certain point? Why doesn't Webkit use those?
For example, for WebAssembly, we measured that the fence instruction was a 5x regression. That’s nuts. Index masking is a rounding error by comparison.
I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.
I really hate to see this rush to "make sure our code doesn't use branch prediction". It may be the best fix we have available now, but it's going to create a legacy of bizarre inefficient machine code that will last forever.
Our mitigations do not prevent branch prediction.
EDIT: I just wanted to clarify here that I did not mean “all branches” just some of them, hence the name of the technique which is “branchless security” (which is a really good piece of engineering). The frustration is basically we have to bake in CPU model specific mitigation’s into binaries. You can of course patch it out, but the affected CPUs will in theory be in the wild for a long time to come even once corrected ones are released.
Earlier quoted context omitted.
Our mitigations do not prevent branch prediction.
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…
I don’t think I will ever forget the line “we cannot trust branches”, it’s just amazing that such a fundamental part of the CPU was broken here.
Does this bode well for Apple code, which seems to tend to pull in innovations from games into the general UI?
Earlier quoted context omitted.
Our mitigations do not prevent branch prediction.
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…
To fix this in hardware without software changes you would have to disable branch prediction. That would perform worse than what we are doing.
Of-course here, the mitigation are being detailed as well.
What is the reasoning behind reusing version numbers?
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.