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

類型一：驗證工程師很容易發現的處理器漏洞！

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

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

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

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

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

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

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

測試平臺已經發現了簡單的bug和幾個極端案例。

我們從這些極端案例中汲取經驗，以改進測試平臺并擴大驗證范圍。這樣做可以使我們發現隱藏漏洞，此時隱藏bug轉變為極端bug（或較容易的bug）。

隨著bug成群結隊的出現，我們可以根據最后發現的bug進一步擴大驗證范圍。

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

類型三：偶然發現的隱匿式CPU 漏洞--或由客戶發現的漏洞！

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

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

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

類型四：在現實生活中不會出現的“silly bugs”！

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

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

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

應用不同的驗證技術，在客戶之前有效地發現CPU漏洞，是Codasip應用的驗證方法。我們使用多個組件測試平臺，各種隨機測試生成器，隨機刺激器，以及其他一些技術來驗證我們的產品。并隨著項目的發展，發展完善這些技術以擁有一個強大的驗證方法。

審核編輯：劉清