This is not really security sensitive now, the exploit is well known now, and v8 appears to be addressing the wip problem with padding, but this is more about performance and wider feedback would be welcomed so please remove the restriction.

I'm pretty sure that the suggested approach won't work. The CPU will just speculate past the branch, and will still access the memory before speculation aborts.

Agree with verwaest@, this is not an effective mitigation.

Closing this issue as "WontFix"--not because we won't fix this bug, but because the suggested approach unfortunately does not work in all cases (as confirmed in internal testing).

Thank you for the feedback. Would you be able to share a case in which it does not work? I know of many issues that would break it, for example if the result of the subtraction spilled to the stack and need to be reloaded, but it would be good to understand the constraints and if they are really hopeless to workaround.

My own limited testing showed that it did address the issue. verwaest@ the proposal does not depend on the processor not speculating past the branch, that can still occur, it is just that the memory access also depends on that input, so when the memory access can proceed the branch that proceeded it also has all its inputs on hand.

Is there any published information about when speculation aborts? Is there any practical limit.

It's very useful to know that speculation occurs and this information can be leaked, but can compiler developers expect any guarantees about when and how speculation ends?

It's getting off topic, but knowing more about how speculation aborts, and any ordering guarantees if any, would be very helpful. Without some confidence it might become impossible to hoist bounds check out of loops etc and compilers might be reduced to unrolling and only hoisting a bounds check above that.

This is not an objection to using masking, rather trying to settle if masking is the only practical solution. 

If you get chip vendors to answer you all these questions, let us know :)

> If you get chip vendors to answer you all these questions, let us know :)

You did claim to have a refutation, and that might be enough to cast this proposal as hopeless?

This proposal does offer some hope, and the alternative might be a huge burden.

I presume you are correct, but still I would like that to be verified and to see that it is hopeless and not something that could be worked around for a potentially better outcome.

Unfortunately we are not able to share PoC due to legal reasons, but roughly, AFAWK the order in which the pending branches are verified is not specified, which can lead to an earlier, much slower, condition allowing the CPU to continue to speculate past the branch in your example.

At this point we are using measures that introduce an explicit data dependency (e.g. poisoning) or remove some of the user-controlled information (e.g. masking).

verwaest's comment was spot on. Vendors are very tight-lipped with their trade secrets :)

Thank you for the confirmation, and for the hints.

Here is another suggestion that avoids any race between the branch and the load and appears to have some potential and might be worth exploring https://weblll.org/index.php/spectre-bounds-check-mitigation-using-a-subtraction-with-borrow/ It uses instructions listed in the Intel publication https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf A key pattern came from the Linux kernel discussions and the uses a subtraction with borrow from zero to generate the mask from the comparison and for the JS sandbox this can be usefully fused with the bounds check branch. Is this something your team has considered for use cases in which arrays not guarded (where the fast strategy used for wasm is not applicable)?