處理器驗(yàn)證：四種CPU bug演變過程

在設(shè)計(jì)一個(gè)復(fù)雜的處理器內(nèi)核時(shí)，可能會(huì)出現(xiàn)1000到2000個(gè)不等的bug，經(jīng)驗(yàn)告訴我們這是事實(shí)，盡管這個(gè)數(shù)字聽上去難以置信。而且并不是所有的bug都是一樣的：它們的重要性和帶來的后果有很大的不同。這期博文讓我們來看看4種不同類型的CPU漏洞，如何找到它們？以及如果我們沒有及時(shí)找到并擊中它們，對(duì)用戶來說會(huì)有著怎么樣的后果？

類型一：驗(yàn)證工程師很容易發(fā)現(xiàn)的處理器漏洞！

類似在設(shè)計(jì)過程中忘記寫入一個(gè)分號(hào)的漏洞類型非常容易發(fā)現(xiàn)，它通常是在編譯時(shí)直接發(fā)現(xiàn)的。對(duì)于此類bug，除了睜大你的眼睛之外，沒有其他辦法來避免！

可能你會(huì)經(jīng)常聽到同事說"哦，這個(gè)規(guī)范的一部分沒有被實(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ī)范，并在開發(fā)過程中隨時(shí)關(guān)注規(guī)范的任何變化。

換句話說，簡(jiǎn)單的bug是指僅僅通過運(yùn)行該功能的測(cè)試就能發(fā)現(xiàn)。它的（壞）行為是系統(tǒng)性的，而不是一個(gè)時(shí)間條件。詳盡的驗(yàn)證是找到這種CPU bug的關(guān)鍵。代碼覆蓋率可以幫助你，但絕對(duì)不夠。如果一個(gè)功能沒有在RTL中編碼，覆蓋率也就不可能報(bào)告它的缺失？此時(shí)需要在規(guī)范明確的情況下執(zhí)行代碼審查。

類型二：驗(yàn)證團(tuán)隊(duì)鐘愛的極端案例!

極端案例下的CPU漏洞找起來比較復(fù)雜，需要一個(gè)強(qiáng)大的測(cè)試平臺(tái)。行使該功能的簡(jiǎn)單測(cè)試用例在有隨機(jī)延遲的情況下也可以通過。很多時(shí)候，當(dāng)異步事件加入時(shí)，就可以發(fā)現(xiàn)這些bug。例如，一個(gè)中斷正好在兩條指令之間到達(dá)，時(shí)間很精確?；蛘弋?dāng)存儲(chǔ)緩沖區(qū)想要合并的時(shí)候，緩存中的一行被驅(qū)逐時(shí)。為了解決這些問題，我們需要一個(gè)測(cè)試平臺(tái)來處理指令、參數(shù)和延遲，從而使所有可能的指令和事件的交錯(cuò)都得到鍛煉。很明顯，一個(gè)好的檢查器應(yīng)該發(fā)現(xiàn)任何與預(yù)期不同的偏差項(xiàng)。

在這種情況下，不幸的是代碼覆蓋率完全沒用。僅僅是因?yàn)閎ug的條件是幾個(gè)事件的組合，而這些事件已經(jīng)被單獨(dú)覆蓋。在這里，條件覆蓋或分支覆蓋可能會(huì)有幫助。但分析起來很痛苦，而且最終也不會(huì)有有效的結(jié)果。

動(dòng)畫顯示了4種類型的CPU bug演變過程

測(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)榇碳さ牟煌梢哉业狡渌穆┒?。那么我們所說的 "偶然發(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)確地說，是六千萬分之一的機(jī)會(huì)。對(duì)于有100條不同指令的RISC-V CPU來說，一個(gè)（可等價(jià)的）隨機(jī)指令發(fā)生器每10?次只有1次機(jī)會(huì)產(chǎn)生連續(xù)10次相同的指令，這種機(jī)率是魔方不同位置數(shù)量的兩倍...... 在一個(gè)10級(jí)流水線處理器上，用所有流水線階段的相同指令來測(cè)試它也不是不合理的。如果此時(shí)還不調(diào)整隨機(jī)約束，那么只能祝你好運(yùn)...

類型四：在現(xiàn)實(shí)生活中不會(huì)出現(xiàn)的“silly bugs”！

如果我們把極端漏洞和隱藏漏洞看得太重，那么最終創(chuàng)建的測(cè)試或許有點(diǎn)徒勞。

在連接調(diào)試器時(shí)，每個(gè)周期來回改變字節(jié)數(shù)，這可能是永遠(yuǎn)不會(huì)出現(xiàn)在消費(fèi)者產(chǎn)品上的案例，如果一個(gè)CPU漏洞的后果對(duì)客戶來說是不可見的，那么它就不是一個(gè)真正的漏洞。如果你在復(fù)制文件時(shí)故意拔掉U盤，而導(dǎo)致文件被損壞，我認(rèn)為這不是一個(gè)bug。如果某些操作導(dǎo)致USB控制器掛起，那么此時(shí)這是一個(gè)不容無視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ù)來驗(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)

編輯：黃飛

?