Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Disclosure: I work on Google Cloud.

Not particularly (if you read Paul's post, the branch to the retpoline predicts perfectly for obvious reasons), and especially not compared to the brute force flushes as an alternative.

Edit: I phrased that backwards. The return predicts, so that the whole thing is about as bad as an unpredicted indirect call:

> This has the particularly nice property that the RSB entry and on-stack target installed by (1) is both valid and used. This allows the return to be correctly predicted so that our simulated indirect jump is the only introduced overhead.



Edit: My post was prior to the parent edit, and now is largely unnecessary. Keeping for posterity, I suppose!

I must be misunderstanding Paul's post.

Isn't it specifically preventing any sort of prediction?

"Naturally, protecting an indirect branch means that no prediction can occur. This is intentional, as we are “isolating” the prediction above to prevent its abuse."

Of course, you can then go and manually add direct branch hints, as is noted in the post, but unless I'm misunderstanding things, there's not an obvious reason why these branches predict perfectly.

Not that it means performance is impacted in a significant way, since that same section also says "Microbenchmarking on Intel x86 architectures shows that our converted sequences are within cycles of an native indirect branch (with branch prediction hardware explicitly disabled)."

(which also confuses this issue - how is it predicting perfectly if prediction hardware is disabled?)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: