在設(shè)計(jì)一個(gè)復(fù)雜的處理器內(nèi)核時(shí),可能會(huì)出現(xiàn)1000到2000個(gè)不等的bug,經(jīng)驗(yàn)告訴我們這是事實(shí),盡管這個(gè)數(shù)字聽(tīng)上去難以置信。而且并不是所有的bug都是一樣的:它們的重要性和帶來(lái)的后果有很大的不同。這期博文讓我們來(lái)看看4種不同類型的CPU漏洞,如何找到它們?以及如果我們沒(méi)有及時(shí)找到并擊中它們,對(duì)用戶來(lái)說(shuō)會(huì)有著怎么樣的后果?
類型一:驗(yàn)證工程師很容易發(fā)現(xiàn)的處理器漏洞!
類似在設(shè)計(jì)過(guò)程中忘記寫入一個(gè)分號(hào)的漏洞類型非常容易發(fā)現(xiàn),它通常是在編譯時(shí)直接發(fā)現(xiàn)的。對(duì)于此類bug,除了睜大你的眼睛之外,沒(méi)有其他辦法來(lái)避免!
可能你會(huì)經(jīng)常聽(tīng)到同事說(shuō)"哦,這個(gè)規(guī)范的一部分沒(méi)有被實(shí)現(xiàn)"。這其實(shí)是另一種極其容易發(fā)現(xiàn)的CPU漏洞,只要有一個(gè)明確的測(cè)試存在,你就可以用任何像樣的測(cè)試平臺(tái)找到它。在這種情況下,行使該功能的第一個(gè)簡(jiǎn)單測(cè)試將失敗。那么此時(shí)處理器驗(yàn)證團(tuán)隊(duì)需要做什么?確保詳盡健全的測(cè)試方式方法是一方面。另一方面,設(shè)計(jì)團(tuán)隊(duì)需要努力仔細(xì)閱讀規(guī)范,并在開(kāi)發(fā)過(guò)程中隨時(shí)關(guān)注規(guī)范的任何變化。
換句話說(shuō),簡(jiǎn)單的bug是指僅僅通過(guò)運(yùn)行該功能的測(cè)試就能發(fā)現(xiàn)。它的(壞)行為是系統(tǒng)性的,而不是一個(gè)時(shí)間條件。詳盡的驗(yàn)證是找到這種CPU bug的關(guān)鍵。代碼覆蓋率可以幫助你,但絕對(duì)不夠。如果一個(gè)功能沒(méi)有在RTL中編碼,覆蓋率也就不可能報(bào)告它的缺失?此時(shí)需要在規(guī)范明確的情況下執(zhí)行代碼審查。
類型二:驗(yàn)證團(tuán)隊(duì)鐘愛(ài)的極端案例!
極端案例下的CPU漏洞找起來(lái)比較復(fù)雜,需要一個(gè)強(qiáng)大的測(cè)試平臺(tái)。行使該功能的簡(jiǎn)單測(cè)試用例在有隨機(jī)延遲的情況下也可以通過(guò)。很多時(shí)候,當(dāng)異步事件加入時(shí),就可以發(fā)現(xiàn)這些bug。例如,一個(gè)中斷正好在兩條指令之間到達(dá),時(shí)間很精確。或者當(dāng)存儲(chǔ)緩沖區(qū)想要合并的時(shí)候,緩存中的一行被驅(qū)逐時(shí)。為了解決這些問(wèn)題,我們需要一個(gè)測(cè)試平臺(tái)來(lái)處理指令、參數(shù)和延遲,從而使所有可能的指令和事件的交錯(cuò)都得到鍛煉。很明顯,一個(gè)好的檢查器應(yīng)該發(fā)現(xiàn)任何與預(yù)期不同的偏差項(xiàng)。
在這種情況下,不幸的是代碼覆蓋率完全沒(méi)用。僅僅是因?yàn)閎ug的條件是幾個(gè)事件的組合,而這些事件已經(jīng)被單獨(dú)覆蓋。在這里,條件覆蓋或分支覆蓋可能會(huì)有幫助。但分析起來(lái)很痛苦,而且最終也不會(huì)有有效的結(jié)果。
動(dòng)畫顯示了4種類型的CPU bug演變過(guò)程
測(cè)試平臺(tái)已經(jīng)發(fā)現(xiàn)了簡(jiǎn)單的bug和幾個(gè)極端案例。
我們從這些極端案例中汲取經(jīng)驗(yàn),以改進(jìn)測(cè)試平臺(tái)并擴(kuò)大驗(yàn)證范圍。這樣做可以使我們發(fā)現(xiàn)隱藏漏洞,此時(shí)隱藏bug轉(zhuǎn)變?yōu)闃O端bug(或較容易的bug)。
隨著bug成群結(jié)隊(duì)的出現(xiàn),我們可以根據(jù)最后發(fā)現(xiàn)的bug進(jìn)一步擴(kuò)大驗(yàn)證范圍。
當(dāng)我們遇到一個(gè)“愚蠢”的bug時(shí),就意味著我們的驗(yàn)證測(cè)試已經(jīng)足夠有效了。
類型三:偶然發(fā)現(xiàn)的隱匿式CPU 漏洞--或由客戶發(fā)現(xiàn)的漏洞!
最壞的情況是如果這種隱藏的bug是由客戶發(fā)現(xiàn)的,或者是偶然發(fā)現(xiàn)的(團(tuán)隊(duì)內(nèi)部或在發(fā)布之前)。出現(xiàn)這兩種情況,這意味著目前的驗(yàn)證方法不足以擊中它們。
如果使用不同的測(cè)試平臺(tái)或環(huán)境,因?yàn)榇碳さ牟煌梢哉业狡渌穆┒?。那么我們所說(shuō)的 "偶然發(fā)現(xiàn) "是什么意思?這里涉及到隨機(jī)測(cè)試平臺(tái)方法的限制。
在隨機(jī)刺激下,測(cè)試平臺(tái)通常會(huì)產(chǎn)生 "相同 "的東西。如果你擲骰子得到一個(gè)隨機(jī)數(shù),連續(xù)10次得到數(shù)字6的機(jī)會(huì)非常少。準(zhǔn)確地說(shuō),是六千萬(wàn)分之一的機(jī)會(huì)。對(duì)于有100條不同指令的RISC-V CPU來(lái)說(shuō),一個(gè)(可等價(jià)的)隨機(jī)指令發(fā)生器每10?次只有1次機(jī)會(huì)產(chǎn)生連續(xù)10次相同的指令,這種機(jī)率是魔方不同位置數(shù)量的兩倍...... 在一個(gè)10級(jí)流水線處理器上,用所有流水線階段的相同指令來(lái)測(cè)試它也不是不合理的。如果此時(shí)還不調(diào)整隨機(jī)約束,那么只能祝你好運(yùn)...
類型四:在現(xiàn)實(shí)生活中不會(huì)出現(xiàn)的“silly bugs”!
如果我們把極端漏洞和隱藏漏洞看得太重,那么最終創(chuàng)建的測(cè)試或許有點(diǎn)徒勞。
在連接調(diào)試器時(shí),每個(gè)周期來(lái)回改變字節(jié)數(shù),這可能是永遠(yuǎn)不會(huì)出現(xiàn)在消費(fèi)者產(chǎn)品上的案例,如果一個(gè)CPU漏洞的后果對(duì)客戶來(lái)說(shuō)是不可見(jiàn)的,那么它就不是一個(gè)真正的漏洞。如果你在復(fù)制文件時(shí)故意拔掉U盤,而導(dǎo)致文件被損壞,我認(rèn)為這不是一個(gè)bug。如果某些操作導(dǎo)致USB控制器掛起,那么此時(shí)這是一個(gè)不容無(wú)視bug。
當(dāng)我們?cè)噲D擴(kuò)大驗(yàn)證的范圍時(shí),如果出現(xiàn)“silly bugs”,那么我們可能是在錯(cuò)誤的地方投入了太多的努力。
應(yīng)用不同的驗(yàn)證技術(shù),在客戶之前有效地發(fā)現(xiàn)CPU漏洞,是Codasip應(yīng)用的驗(yàn)證方法。我們使用多個(gè)組件測(cè)試平臺(tái),各種隨機(jī)測(cè)試生成器,隨機(jī)刺激器,以及其他一些技術(shù)來(lái)驗(yàn)證我們的產(chǎn)品。并隨著項(xiàng)目的發(fā)展,發(fā)展完善這些技術(shù)以擁有一個(gè)強(qiáng)大的驗(yàn)證方法。更多關(guān)于處理器驗(yàn)證方法,請(qǐng)關(guān)注我們的系列博文,了解Codasip如何不斷改進(jìn)驗(yàn)證方法,以獲得最高品質(zhì)的處理器產(chǎn)品。
作者:
Philippe Luc
Codasip驗(yàn)證事業(yè)部總監(jiān)
編輯:黃飛
?
評(píng)論
查看更多