4種應該注意的CPU漏洞
作者 : Philippe Luc，Codasip驗證事業部總監
本文提出4種不同類型的CPU漏洞、如何找到這些bug的方法，以及如果沒能及時找到並正確除錯，對用戶來說會有著怎麼樣的後果？
在設計一款複雜的處理器核心時，可能會出現1,000到2,000個不等的漏洞(bug)，經驗告訴我們這是事實，儘管這個數字聽上去難以置信。而且並不是所有的bug都是一樣的：它們的重要性和帶來的後果有很大的不同。
本文讓我們來看看4種不同類型的CPU漏洞，如何找到這些bug？以及，如果我們沒有及時找到並正確除錯，對用戶來說會有著怎麼樣的後果？
類型一：驗證工程師很容易發現的處理器漏洞！
類似在設計過程中忘記寫入一個分號的漏洞類型非常容易發現，它通常是在編譯時直接發現的。對於此類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應用的驗證方法。透過使用多個組件測試平台，各種隨機測試產生器、隨機刺激器，以及其他一些技術來驗證產品，並隨著專案的發展，可望發展完善這些技術以擁有一個強大的驗證方法。
本文原刊登於EDN China網站，趙明燦編譯
加入LINE@，最新消息一手掌握！
