處理器驗證：四種CPU bug演變過程

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

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

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

可能你會經(jīng)常聽到同事說"哦，這個規(guī)范的一部分沒有被實現(xiàn)"。這其實是另一種極其容易發(fā)現(xiàn)的CPU漏洞，只要有一個明確的測試存在，你就可以用任何像樣的測試平臺找到它。在這種情況下，行使該功能的第一個簡單測試將失敗。那么此時處理器驗證團隊需要做什么？確保詳盡健全的測試方式方法是一方面。另一方面，設(shè)計團隊需要努力仔細閱讀規(guī)范，并在開發(fā)過程中隨時關(guān)注規(guī)范的任何變化。

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

類型二：驗證團隊鐘愛的極端案例!

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

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

動畫顯示了4種類型的CPU bug演變過程

測試平臺已經(jīng)發(fā)現(xiàn)了簡單的bug和幾個極端案例。

我們從這些極端案例中汲取經(jīng)驗，以改進測試平臺并擴大驗證范圍。這樣做可以使我們發(fā)現(xiàn)隱藏漏洞，此時隱藏bug轉(zhuǎn)變?yōu)闃O端bug（或較容易的bug）。

隨著bug成群結(jié)隊的出現(xiàn)，我們可以根據(jù)最后發(fā)現(xiàn)的bug進一步擴大驗證范圍。

當我們遇到一個“愚蠢”的bug時，就意味著我們的驗證測試已經(jīng)足夠有效了。

類型三：偶然發(fā)現(xiàn)的隱匿式CPU 漏洞--或由客戶發(fā)現(xiàn)的漏洞！

最壞的情況是如果這種隱藏的bug是由客戶發(fā)現(xiàn)的，或者是偶然發(fā)現(xiàn)的（團隊內(nèi)部或在發(fā)布之前）。出現(xiàn)這兩種情況，這意味著目前的驗證方法不足以擊中它們。

如果使用不同的測試平臺或環(huán)境，因為刺激的不同可以找到其他的漏洞。那么我們所說的 "偶然發(fā)現(xiàn) "是什么意思？這里涉及到隨機測試平臺方法的限制。

在隨機刺激下，測試平臺通常會產(chǎn)生 "相同 "的東西。如果你擲骰子得到一個隨機數(shù)，連續(xù)10次得到數(shù)字6的機會非常少。準確地說，是六千萬分之一的機會。對于有100條不同指令的RISC-V CPU來說，一個（可等價的）隨機指令發(fā)生器每10?次只有1次機會產(chǎn)生連續(xù)10次相同的指令，這種機率是魔方不同位置數(shù)量的兩倍...... 在一個10級流水線處理器上，用所有流水線階段的相同指令來測試它也不是不合理的。如果此時還不調(diào)整隨機約束，那么只能祝你好運...

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

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

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

當我們試圖擴大驗證的范圍時，如果出現(xiàn)“silly bugs”，那么我們可能是在錯誤的地方投入了太多的努力。

應(yīng)用不同的驗證技術(shù)，在客戶之前有效地發(fā)現(xiàn)CPU漏洞，是Codasip應(yīng)用的驗證方法。我們使用多個組件測試平臺，各種隨機測試生成器，隨機刺激器，以及其他一些技術(shù)來驗證我們的產(chǎn)品。并隨著項目的發(fā)展，發(fā)展完善這些技術(shù)以擁有一個強大的驗證方法。更多關(guān)于處理器驗證方法，請關(guān)注我們的系列博文，了解Codasip如何不斷改進驗證方法，以獲得最高品質(zhì)的處理器產(chǎn)品。

作者：