【原创】chrome已提交的两个漏洞分析(四)

但是这么做也有问题，那就是当CheckBounds被替换为新节点后需要再一次typer来给替换上的节点加上type，而以上做法并不会触发再一次typer，解决方法如下。
However, there is an additional problem: While the CheckBounds-node is inserted, the type of the addition itself actually never gets updated, as there is nothing to trigger a re-typing.

This can be fixed by adding a larger number like 2**30, which will result in a NumberOperationHint of kNumber instead of kSignedSmall, which will make typed-optimization.cc change the node into a regular NumberAdd during the LoadElimination-phase.
对应代码
Reduction TypedOptimization::ReduceSpeculativeNumberAdd(Node* node) {
...

NumberOperationHint hint = NumberOperationHintOf(node->op());
if ((hint == NumberOperationHint::kNumber ||
hint == NumberOperationHint::kNumberOrOddball) &&
BothAre(lhs_type, rhs_type, Type:lainPrimitive()) &&
NeitherCanBe(lhs_type, rhs_type, Type::StringOrReceiver())) {
// SpeculativeNumberAdd(x:-string, y:-string) =>
// NumberAdd(ToNumber(x), ToNufunction bar(a, arg_true) {
Node* const toNum_lhs = ConvertPlainPrimitiveToNumber(lhs);
Node* const toNum_rhs = ConvertPlainPrimitiveToNumber(rhs);
Node* const value =
graph()->NewNode(simplified()->NumberAdd(), toNum_lhs, toNum_rhs);
ReplaceWithValue(node, value);
return Replace(value);
}
return NoChange();
}
上面我们加上2**30后当然需要再减去，所以
We then subtract 2**30 again, resulting in a SpeculativeNumberSubtract-node that is again replaced by a regular NumberSubtract.
Once everything has been lowered to 32-bit integer operations, the addition and subtraction will be combined to an addition of 0 and then eliminated, thus they aren’t interfering with triggering the wrong optimization.
当然为了防止常量折叠使得我们一次加一次减直接被优化消失掉，我们还需要引入一个未知变量，所以我们可以把原本2**30的地方改为2**30 – (c0&1)，这样(o.cf ? “” : (2**30) – (o.c0&1)) – (2**30)最后的type就是Range(-1, 0)而不是(0, 0)，还能防止被优化掉。
#【原创】chrome已提交的两个漏洞分析(五)#

不错 支持下

看起来不错

一直在看

不错 支持下

确实不错，顶先