Hacker News Reader

Comment by pizlonator | Hacker News Reader

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 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.

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.

That is super cool. I had no idea a lot of this was JIT side, and I do agree this is one of the best fixes I have seen for this yet.

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 assuming sommeone clever at Intel will come up with some security non Perf killing change to make branches trustable again).

Now we are doing both bounds check branches and index masking. The index masking is purely additive. We didn't replace branches.

Similarly, where we use pointer poisoning, it is in addition to some other security check, which is almost always a branch.

Also, security aside, removing (mispredicted) branches is a legitimate way to try to speed up code!

Reply on news.ycombinator.com