基于B/S 結(jié)構(gòu)的多核微處理器實速故障診斷技術(shù)

高吉普，徐長寶，辛明勇，陳軍健，劉德宏

（1.貴州電網(wǎng)有限責(zé)任公司電力科學(xué)研究院，貴州貴陽 550002；2.南方電網(wǎng)數(shù)字電網(wǎng)研究院有限公司，廣東 廣州 510663）

多核微處理器在數(shù)據(jù)并行處理方面，有很大的優(yōu)勢。該處理器通過加載和存儲指令對共享主存進行訪問，能夠保持完整的地址空間，且每個微處理器都具備獨立專用緩存模塊。由于IC 設(shè)計技術(shù)和制造技術(shù)的不斷發(fā)展，芯片集成設(shè)計變得越來越復(fù)雜，晶片體積越來越小是造成芯片制造缺陷的主要原因，而故障檢測僅僅局限于對芯片進行篩選，無法及時發(fā)現(xiàn)故障問題，為此，各大學(xué)者提出了故障診斷技術(shù)。文獻[1]提出了BC 網(wǎng)絡(luò)的g-超條件診斷度技術(shù)，在每一個由非故障節(jié)點組成的分支中至少有g(shù)+1 個頂點時，系統(tǒng)能一次性識別出故障節(jié)點數(shù)量，從而能夠?qū)Ξ悩?gòu)環(huán)境下系統(tǒng)互連網(wǎng)的自故障診斷進行精確測量；文獻[2]提出了強魯棒性開路故障診斷策略，通過構(gòu)造一種非對稱負載和非平衡空載系統(tǒng)，結(jié)合改進歸一化平均電流派克矢量模型，實現(xiàn)故障診斷。然而這兩種技術(shù)受到多核微處理器系統(tǒng)并發(fā)不確定性影響，導(dǎo)致即使利用同一個測試用例進行多次測試，也無法保證所有測試用例都能得到充分測試。因此，提出了一種基于B/S結(jié)構(gòu)的多核微處理器實速故障診斷技術(shù)。

1 故障診斷原理分析

多核微處理器是目前應(yīng)用最多的處理器，其包括兩個以上完整的計算機引擎，通過控制總線的全部指令信號，能夠支持多核微處理器同時在線運行。通過分析多核微處理器故障診斷原理，設(shè)計詳細的診斷流程。

1.1 基于B/S結(jié)構(gòu)的多核微處理器

使用的一種基于B/S 結(jié)構(gòu)的多核微處理器，其結(jié)構(gòu)是在信息技術(shù)不斷進步和發(fā)展的背景下產(chǎn)生的，彌補了傳統(tǒng)C/S 體系結(jié)構(gòu)的缺陷。

基于B/S結(jié)構(gòu)的多核微處理器結(jié)構(gòu)圖如圖1所示。

圖1 基于B/S結(jié)構(gòu)的多核微處理器

由圖1 可知，該處理器主要是由表示層、業(yè)務(wù)層和數(shù)據(jù)層組成的，通過任務(wù)分配完成網(wǎng)絡(luò)分析與挖掘[3]。該過程涉及到大量的數(shù)學(xué)運算，為提高多核微處理器性能，瀏覽器端負責(zé)內(nèi)容的顯示和交互，服務(wù)器端負責(zé)復(fù)雜的數(shù)據(jù)計算和邏輯處理[4]。采用B/S 結(jié)構(gòu)的多核微處理器實現(xiàn)了“分而治之”的策略，線程化應(yīng)用程序通過分解模式，在給定時間使用多個執(zhí)行內(nèi)核執(zhí)行更多的任務(wù)[5]。

1.2 故障診斷原理

1.2.1 返回地址堆棧

由于呼叫指令CALL 與IP 內(nèi)容修改指令是一一對應(yīng)的，所以返回地址堆棧是一個硬件堆棧，主要用于存儲返回的目標(biāo)地址信息。因此，當(dāng)呼叫指令CALL 出現(xiàn)時，多核微處理器的處理程序?qū)l(fā)出下一條呼叫指令，并將返回的目標(biāo)地址信息壓入返回地址堆棧頂部[6]。當(dāng)IP 內(nèi)容修改指令出現(xiàn)時，多核微處理器會自動彈出返回地址堆棧頂部的目標(biāo)地址，如果返回的目標(biāo)地址無法在所有返回地址中找到，那么說明多核微處理器的處理過程失敗[7]。

1.2.2 面向返回編程

面向返回編程可以對ret-to-lib 攻擊進行診斷，其中攻擊者重用整個LIBC 庫，在故障診斷過程中，從存儲器(目標(biāo)程序或者共享庫)中找到一段代碼，然后構(gòu)建一個有效的插件把一系列Gadget 連接起來[8]。

圖2 顯示了基于B/S 結(jié)構(gòu)的多核微處理器的故障診斷原理。

圖2 基于B/S結(jié)構(gòu)的多核微處理器的故障診斷原理

由圖2 可知，在Return 指令中，可以使用庫文件中的Gadget 鏈接執(zhí)行故障排除操作[9]。

2 多核微處理器實速故障診斷

2.1 死鎖故障診斷

死鎖場景是在開發(fā)多核微處理器時，驗證芯片是否能夠正常工作時出現(xiàn)的場景，由共享響應(yīng)通道引起的死鎖場景如圖3 所示。

圖3 由共享響應(yīng)通道引起的死鎖場景

由圖3 可知，E1-E8 表示路由器，H1-H8 表示跟蹤節(jié)點，R1-R8 表示推送節(jié)點，S1-S8 表示請求節(jié)點。WBD 技術(shù)的應(yīng)用改善了替代運營協(xié)議的性能，由于數(shù)據(jù)需要返回到WBD 事務(wù)，因此必須為傳輸數(shù)據(jù)分配通道[10]。

在執(zhí)行期間，寫回請求由跟蹤節(jié)點到請求節(jié)點的響應(yīng)通道發(fā)送。例如，H2 通過響應(yīng)通道將回寫請求發(fā)送到S2[11]。因為多核微處理器支持請求節(jié)點，所以直接將數(shù)據(jù)推給請求節(jié)點，因此，該過程存在通道共享：舉例來說，S4 將讀取的響應(yīng)包推到S6，而且還使用R2 到R3 響應(yīng)通道[12]。在共享信道時會出現(xiàn)死鎖可能，因此，在芯片模擬仿真過程中的確出現(xiàn)了死鎖。據(jù)此，設(shè)計了死鎖故障診斷步驟如下：

步驟一：通過動態(tài)配置的緩存一致性協(xié)議，可以應(yīng)用到不同的多核微處理器中。根據(jù)多核微處理器結(jié)構(gòu)，對功能和性能的要求進行功能容錯和性能調(diào)整。在可配置協(xié)議的基礎(chǔ)上，引入了微操作機制的分布式目錄控制器[13-14]。圖4 展示了分布式目錄控制器的總體結(jié)構(gòu)。

圖4 分布式目錄控制器的總體結(jié)構(gòu)

步驟二：目錄是通過硬件工作后生成的，優(yōu)點是速度快，缺點是很難修改。引入微操作機制后，通過配置一致性協(xié)議，能夠通過改變相關(guān)程序來改變信號傳輸路徑。

步驟三：死鎖通過監(jiān)視跟蹤節(jié)點和請求節(jié)點之間的讀寫事務(wù)等待時間，判斷是否發(fā)生了死鎖。

步驟四：為了提高性能，跟蹤節(jié)點和請求節(jié)點的默認協(xié)議為WBD 協(xié)議。若等待時間超過某一閾值，跟蹤節(jié)點和請求節(jié)點之間的鏈路就會阻塞，還可能出現(xiàn)死鎖。

步驟五：分布式目錄控制器進入調(diào)試模式，將寫回數(shù)據(jù)(WBD)轉(zhuǎn)換為請求協(xié)議，啟動重傳機制后，逐步清除阻塞鏈。在釋放死鎖之后，它會恢復(fù)到正常模式和WBD，以高性能形式繼續(xù)診斷[15]。

2.2 鏈路故障診斷

對于鏈路故障問題，需通過測試能夠確定多核微處理器是否存在故障問題[16]。

以單輸出響應(yīng)為例，可將電路輸入響應(yīng)序列集合描述為：

式中，xn表示輸入響應(yīng)序列。

結(jié)合輸出向量函數(shù)，構(gòu)建電路輸出響應(yīng)表達式：

式中，f(·)表示輸出函數(shù)。

在輸入激勵作用下，有：

式中，an表示激勵序列，λ表示激勵參數(shù)。

對于故障，存在：

當(dāng)計算結(jié)果符合式（4）時，表明鏈路有故障，通過測試代碼λ可以發(fā)現(xiàn)故障。

3 實 驗

為了驗證提出的基于B/S 結(jié)構(gòu)的多核微處理器實速故障診斷技術(shù)研究合理性，進行實驗驗證分析。

3.1 實驗設(shè)置

在32 位Ubuntu14.04 操作系統(tǒng)上建立了ROP 攻擊的實驗平臺，以驗證面向返回轉(zhuǎn)換的ROP 攻擊的效果。

3.1.1 參數(shù)設(shè)置

不同ROP 攻擊的診斷周期決定了診斷的準(zhǔn)確性，這取決于其鏈長。因此，小型鏈長一般為10～15 hops。設(shè)置Gadget 鏈的長度為15 hops。為減少誤報和漏報現(xiàn)象，實現(xiàn)最佳診斷效果，將診斷周期設(shè)為6 s 或9 s，并進行對比實驗。

3.1.2 ROP真實攻擊診斷

在Ubuntu 下，用ROP 漏洞選擇四個小程序，要求一串較長的輸入?yún)?shù)，該程序需要GCC 編譯為二進制可以執(zhí)行的文件。四個程序漏洞說明如表1所示。

表1 程序漏洞說明

用ROPgadget 構(gòu)建了30 條Gadget 鏈，這30個攻擊腳本是從數(shù)據(jù)庫中選擇的。每一條Gadget 鏈的長度均超過15 hops，總共進行了30 次攻擊。

3.2 性能評估

為了評估所研究方法在真實操作中的總體性能，使用UnixBench5.1.3 對多核微處理器性能進行評估。在ROP 攻擊下，選用UnixBench 對基于B/S 結(jié)構(gòu)的多核微處理器進行整體性評估。將性能測試工具應(yīng)用到Linux 系統(tǒng)中，測試的項目包括字符串處理、浮點運算、調(diào)用、管道吞吐、管道上下文交互、函數(shù)吞吐、文件讀寫、腳本測試。對于這些項目，使用多核微處理器的處理時間如表2 所示。

表2 測試項目處理時間對比分析

由表2 可知，在ROP 攻擊下，診斷項目處理速率均在可接受范圍之內(nèi)。

基于此，分別使用g-超條件診斷度技術(shù)、強魯棒性開路故障診斷策略和基于B/S 結(jié)構(gòu)的多核微處理器實速故障診斷技術(shù)，對比分析項目處理速率，對比結(jié)果如圖5 所示。

圖5 三種診斷技術(shù)項目處理時間對比

由圖5 可知，使用g-超條件診斷度技術(shù)處理除了字符串項目外，其余均超過標(biāo)準(zhǔn)時間，其中處理調(diào)用項目所耗費時間最長為83 s；使用強魯棒性開路故障診斷策略處理除了字符串項目外，其余均超過標(biāo)準(zhǔn)時間，其中處理調(diào)用項目所耗費時間最長為79 s；使用基于B/S 結(jié)構(gòu)的多核微處理器實速故障診斷技術(shù)，除了管道吞吐項目比標(biāo)準(zhǔn)時間長1 s 外，其余所有項目處理時間均在標(biāo)準(zhǔn)時間范圍內(nèi)。

4 結(jié)束語

在B/S 結(jié)構(gòu)的基礎(chǔ)上，提出了多核微處理器實時故障診斷技術(shù)，通過一致性協(xié)議能夠顯著提高不同架構(gòu)下系統(tǒng)的靈活性。由實驗結(jié)果可知，該技術(shù)具有良好的診斷效果。然而，由于不同的配置不能形成統(tǒng)一的緩存一致性協(xié)議，導(dǎo)致了極大的死鎖風(fēng)險。為此，需要設(shè)置一致性緩存協(xié)議，以達到靈活配置，以優(yōu)化更大的空間，保證一致性協(xié)議的使用更加合理。