国产成人毛片毛片久久网_国产午夜激无码av毛片不_国产乱对白精彩在线播放_av资源站中文字幕_亚洲男人的天堂网站_国产成 人 综合 亚洲网_中国国产激情一区_少妇一级淫片免费放_亚洲一本大道av久在线播放_免费观看美女裸体网站

    環(huán)境準(zhǔn)備

            git reset--hard df52b65dba782a6bbef0b64684795bcea3503607gclient sync
        

    Patch分析

            diff --git a/src/compiler/type-cache.h b/src/compiler/type-cache.hindex ada95a3..2ade5f6 100644--- a/src/compiler/type-cache.h+++ b/src/compiler/type-cache.h@@ -80,7 +80,7 @@Type::Union(kPositiveIntegerOrMinusZero, Type::NaN(), zone());Type const kAdditiveSafeInteger =- CreateRange(-4503599627370496.0, 4503599627370496.0);+ CreateRange(-4503599627370495.0, 4503599627370495.0);Type const kSafeInteger = CreateRange(-kMaxSafeInteger, kMaxSafeInteger);Type const kAdditiveSafeIntegerOrMinusZero =Type::Union(kAdditiveSafeInteger, Type::MinusZero(), zone());
        

    poc是把kAdditiveSafeInteger這個(gè)const的范圍給更新了一下，根據(jù)名字來看應(yīng)該是做加法的整數(shù)的安全范圍，反向查找一下引用，發(fā)現(xiàn)也只有在這里被引用了一次，還有一次是在下面對(duì)kAdditiveSafeIntegerOrMinusZero的賦值，僅此兩次。

    然后繼續(xù)反向找一下kAdditiveSafeIntegerOrMinusZero，發(fā)現(xiàn)在compiler/simplified-lowering.cc下有幾個(gè)引用，具體做什么用現(xiàn)在現(xiàn)在還不是很清楚。

    issue里面給了POC ，先來分析這個(gè)POC。

    POC分析

            // the first function exists to generate the SpeculativeSafeIntegerAdd nodefunctionbar(a,b) {a = a|0;b = b|0;var x = a*(2**30) + b; // constrain x to be an integerx = Math.min(Math.max(x,0),4503599627370496) // further constrain to kAdditiveSafeIntegerreturn (x+x)|0; // the actual addition, plus the truncation to Word32}functionfoo(a,b) {a = a|0;a = Math.min(Math.max(a,4194304),4194304);b = b|0;b = Math.min(Math.max(b,2**30-2),2**30); // these constraints will mean that x has type Range(4503599627370496, 4503599627370496)// the result of bar will be typed to the intersection of// Range(-9007199254740991, 9007199254740991) and Range(9007199254740992, 9007199254740992)// which is empty; the dead code elimination emits a Throwreturn bar(a,b);}%PrepareFunctionForOptimization(bar);bar(0,1,0);%OptimizeFunctionOnNextCall(bar);bar(0,1,0);%PrepareFunctionForOptimization(foo);console.log(foo(0,2**29-1));%OptimizeFunctionOnNextCall(foo);console.log(foo(0,2**29-1));
        

    根據(jù)POC的寫法，猜測(cè)是Type的BUG，運(yùn)行一下看一下

    發(fā)現(xiàn)憑空插入一個(gè)斷點(diǎn)，我們來分析下這個(gè)錯(cuò)誤是如何生產(chǎn)的。

    漏洞分析

    trace-turbo 生成IR圖，直接對(duì)IR操作。查看最終生成的代碼。

    發(fā)現(xiàn)這里意外有個(gè)unreachable，顯然是BUG生成的。然后看下schedule階段。

    不出所料果然是有個(gè)unreachable，然后查看一下這個(gè)節(jié)點(diǎn)的起源。

    #180節(jié)點(diǎn)在 simplified lowering 階段被替換。那就去找下。

    發(fā)現(xiàn)這邊還有一個(gè)209 也是。在后面沒有原因應(yīng)該是代碼亢余消除階段給消了。

    對(duì)#209節(jié)點(diǎn)重復(fù)上面操作。發(fā)現(xiàn)是在typerlowering階段替換的。而此時(shí)我們看到了未被替換的修改的#180節(jié)點(diǎn)也就是#227的前身。

    繼續(xù)查找，發(fā)現(xiàn)#209 是在這個(gè)階段被DeadCodeElimination生成的。

    然后看下上面一個(gè)階段，發(fā)現(xiàn)其還未被替換。

    至于為什么被替換，根據(jù)issue給的解釋是因?yàn)?180的兩個(gè)valueinput也就是上圖顯示的#202節(jié)點(diǎn)下面的range，兩個(gè)傳入的都是4503599627370496，也就是patch修改之后的值，然后兩個(gè)#202 被 #180操作之后為9007199254740992，超過 kMaxSafeInteger=9007199254740991，溢出了一個(gè)1，正好因?yàn)檫@個(gè)1導(dǎo)致了#180的type 被設(shè)置為了None。然后由于type 的錯(cuò)誤，后面的也會(huì)被設(shè)置為None，然后在typerlowering階段的DeadCodeElimination里面由于#180的none ，然后由于#180 作為#181的effect，所以在這被替換為unreachable。（patch之后 計(jì)算的值在合適的范圍內(nèi)就不會(huì)產(chǎn)生BUG）。

    然后在simplelowering 階段 #180由于range為none，而最終被替換成unreachable。

    然后在simplelowering 階段 #180由于range為none，而最終被替換成unreachable。

    至此分析完畢。