封包關聯技術之實作

本節將介紹我們根據第 4.5 節的封包關聯技術之設計實作本技術，並且運行 於 Linux 核心系統。由於我們必頇事先從核心系統之中取得 KBL，而本論文的 選擇性指令嵌入技術，可以嵌入指令於核心系統內部所有的封包處理函式，因此 我們利用該技術得到嵌入指令的核心系統，再從該核心系統取得 KBL。然而選 擇性指令嵌入技術所嵌入的指令是建立於動態指令嵌入平台[48]之上，因此本技 術必頇實作該平台中，實際記錄資訊的核心模組，才得以記錄的最少封包相關資 料及它經過處理函式的順序與時間點，再將之統整為 KBL。

5.3.1 Instrument Module 之實作

我們根據第 4.5 節的設計，實作 Instrument Module 來取得 KBL，如 Figure 4-12 與 Figure 4-13。然而 KBL 原本的設計實作於 Linux 核心系統會有困難，因此我 們修改部分內容，但不影響原本的設計目的。

KBL 於 Linux 核心系統實際取得的資訊，修改的部分為 ID of Function 與 ID of Caller，我們改為取得函式與 Caller 的記憶體位址。因為 Linux 核心系統於編 譯時，會產生 Kernel Symbol Table，其內部存有每一個函式與其對應的記憶體位 址，如 Figure 5-5。因此我們不需要於選擇性指令嵌入技術之中，為每一個函式 指定對應的 ID，並且修改原始程式碼，使得該函式取得 Caller 的 ID。因此我們 利用 Gcc Compiler 的內建函式：__builtin_return_address，取得 Caller 的記憶體 位址。如此一來，即可達成原本設計 ID of Function 與 ID of Caller 辨識執行函式 的目的。

Address Function Name

Figure 5-5 Kernel Symbol Table

KBL 中的 Footprint，修改的部分為 ID of Packet，我們改為記錄 struct sk_buff 的記憶體位址。因為如果要為每一個網路封包標識 ID，就必頇於網路通訊協定 堆疊的入口函式指定一個 ID 給每一個網路封包，然而 Linux 核心系統的網路通 訊協定堆疊的入口函式不只一個，因此無法指定 ID 給每一個網路封包。最後我 們觀察 Linux 核心系統於函式之間傳遞 struct sk_buff，是利用 Call By Reference，

所以改為記錄 struct sk_buff 的記憶體位址，即能達成原本利用 ID of Packet 辨識

KBL Footprint 1

1 8 1 Dest. IP Source IP Ident. Protocol

2

4 4 2 1

Figure 5-6 封包關聯技術實際儲存格式

然而以上修改的部分，皆需要於 Linux 核心系統中取得，再傳遞到 Instrument Module，因此 Direct use function Module 與 Indirect use function Module 將嵌入相 關的指令於探針之中，之後讓 Instrument Module 取得其餘的資訊。

另一方面，由於我們必頇降低本工具對於核心系統與其網路通訊協定堆疊的 負擔，避免產生對於剖析與除錯結果的誤判。從先前的研究中[15][48]，得知造 成系統負擔的最大因素在於記錄資訊的指令。因此我們選用對於系統負擔較小的 記錄方法，即是先將資訊記錄於 Memory 之中，過一段時間之後，由 Log Monitor 將記錄的資訊從 Memory 搬移到 Disk。

因為需要將資訊記錄於記憶體之中，所以必頇事先取得記憶體空間，然而我 們無法於 Instrument Module 記錄資訊時動態分配記憶體空間。由於動態分配記 憶體空間，將使核心系統產生 Context Switch，影響網路封包於網路通訊協定堆 疊的原始處理過程，以及造成系統負擔。因此我們利用 Instrument Module 經由 relayfs 事先取得一大塊連續的記憶體空間，之後將資訊記錄於此連續的記憶體空 間。

但是選擇性指令嵌入技術無法判斷尋找到的封包處理函式是運作於 Process Context 或者 Interrupt Context，因此可能會發生某一些函式正在透過 Instrument Module 記錄資訊到 Memory 時被中斷，而 Interrupt routine 之中，也會有封包處 理函式透過 Instrument Module 記錄資訊到 Memory，因而產生記錄資訊混亂的情 況，如 Figure 5-7。

KBL of FunA FunA

FunB

FunA Interrupt

KBL of FunB KBL of FunA (Conti.) Memory

因此我們使用 Atomic Operation Mechanism，即是當函式記錄資訊到記憶體 時關閉 Interrupt，避免產生如 Figure 5-7 的 Race Condition 情形，雖然關閉 Interrupt 會影響原本網路協定堆疊的運作，然而這是無法避免的問題，而且 KFT[8]也採 用此種作法，但是我們將於第六章說明本工具對於系統的負擔，以及網路協定堆 疊的影響，遠比 KFT 低。

5.3.2 Log Monitor 之實作

由於 Instrument Module 是利用 relayfs 取得記憶體空間，因此 Log Monitor 只需要利用 Linux 存取檔案的 System Call，來存取 relayfs 的虛擬檔案，即能將 Instrument Module 記錄於 Memory 的資訊搬移到 Disk，並且儲存成 KBL。

5.3.3 Log Matcher 之實作

Log Matcher 使用 Qt4 實作，讓使用者輸入整倂 KBL 與 PBL 所需的封包資訊，

然後根據 5.3.1 節的 Figure 5-6 之格式解析 KBL，並且找出該封包於核心系統的 運作過程，如 Figure5-8。圖中方框虛線為使用 IP Header 的資訊找出該封包的運 作過程。

Matching

Figure 5-8 Log Matcher 之運作畫面