網路通訊協定堆疊剖析暨除錯之選擇性指令嵌入與封包關聯技術

國

立

交

通

大

學

資訊科學與工程研究所

碩

士

論

文

網路通訊協定堆疊剖析暨除錯之選擇性指令嵌

入與封包關聯技術

Selective Instrumentation and Packet Association for Profiling

and Debugging Network Protocol Stacks

研 究 生：李宗鴻

指導教授：曹孝櫟 教授

曾建超 教授

網路通訊協定堆疊剖析暨除錯之選擇性指令嵌入與封包關連技術

Selective Instrumentation and Packet Association for Profiling and

Debugging Network Protocol Stacks

研 究 生：李宗鴻 Student：Tsung-Hung Li

指導教授：曹孝櫟 Advisor：Shiao-Li Tsao

曾建超 Chien-Chao Tseng

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science June 2010

Hsinchu, Taiwan, Republic of China

網路通訊協定堆疊剖析暨除錯之選擇性指令嵌

入與封包關聯技術

研究生: 李宗鴻 指導教授: 曹孝櫟 教授

曾建超 教授

國立交通大學資訊科學與工程研究所

摘 要

本研究之目的是發展選擇性指令的嵌入技術以及核心行為與網路封包的關 連機制。網路通訊協定堆疊的運作，包含裝置系統內部的網路核心行為(包含核 心函式的執行與核心事件的產生)，以及外顯的網路協定行為，因此，為了了解 裝置的整體通訊行為，我們需要整合網路核心系統的執行紀錄，以及網路協定在 裝置間交換的封包紀錄。雖然，網路封包擷取工具可以擷取封包，紀錄網路協定 外顯的封包交換行為，但目前尚未有一套工具能夠有效完整地記錄核心系統內部 處理封包的行為，並且將系統內部的核心行為與外顯的網路協定行為整併，以追 蹤與剖析網路通訊協定堆疊的完整運作程序。 因此，本論文提出一套選擇性指令的嵌入機制，該機制可以在核心程式中選 擇適當的嵌入點嵌入指令，祇記錄必要的核心行為發生的時間點，以及與封包關 聯的資訊，利用這些紀錄，我們可以將核心行為的紀錄與網路封包整合，展現網 通裝置的整體通訊行為，讓開發者可以剖析裝置的網路協定堆壘運作，釐清與改 善網路通訊的問題，提升開發效率與通訊效能。 本論文首先於作業系統的網路通訊協定堆疊之上，設計一套追蹤網路封包處 理程序的機制，該機制從核心系統的原始程式碼中，找出存取封包的函式，並且 嵌入能記錄執行函式與封包相關資訊的指令於該函式內，讓開發者得以追蹤系統 內部處理網路封包的行為與時間點。接著提出一套對應整體通訊行為的方法，即 將核心行為記錄與網路協定行為記錄作對應，讓開發者可以進一步分析核心運作 與網路封包傳遞之間的互相影響，達成整合除錯的目的。 最後利用其他手動追蹤網路封包處理程序的方法來驗證本論文尋找網路封 包處理函式的準確性，以及利用網路效能測詴程式，來比較本論文所提出的機制 與其他核心函式追蹤工具對於作業系統處理封包速度的影響程度。實驗結果顯 示，本論文所提出的追蹤封包處理程序機制能夠確實地找到網路封包處理函式， 並且對於作業系統的影響程度是非常小的。另一方面，我們使用 TCP 的 Three-way-handshake 之過程，驗證本論文整倂核心行為記錄與網路協定記錄的

關鍵詞：Linux、網路通訊協定堆疊、嵌入式系統、核心函式、開放原始碼、封 包處理過程

Selective Instrumentation and Packet Association for Profiling

and Debugging Network Protocol Stacks

Student: Tsung-Hung Li Advisor: Dr. Shiao-Li Tsao Dr. Chien-Chao Tseng Institute of Computer Science and Engineering

College of Computer Science National Chiao Tung University

Abstract

New network communication applications such as cloud computing boost the need of the small and compact interaction gadgets. Such gadgets are compact and small devices that developers have tried hard to make them more reliable and powerful. Tools like kernal profilers and packet tracer help developers to analyze the behavior of the device internally and externally, respectively.. However, there still does not have any tool that can capture the overall networking behavior and help us to investigate and debug the network protocol stack or networking protocol.

This thesis aims to develop a selective instrumentation and packet association mechanism that can automatically select network kernel functions and patch instructions to record the times functions start or termine as well as the information used to associate kernel function log with packet tracers's outputs. The selection instrumentation uses the special data-structure Linux Kernels use to maintain packets being processed to identify the network kernel functions. Experimental results show that the selective instrumentation and packet association mechanism is very effective and can indeed help to derive the overall networking behavior, including both internal network kernel operations and external communication behaviors. In the future, we could extend the work of this thesis to develop an analyzer that can fileter irrelated information and automatically thynthesize the networking behavior of interest, and help users to identy design flaws or the bottlenecks of the networking protocols or network kernels.

誌 謝

首先，感謝曾建超老師這兩年來的指導以及支持，不管是在專業知識的訓 練上、相關資訊的提供以及實驗中所需要用到的設備儀器等等，老師都給予我相 當多的幫助，讓我有如此豐富的資源，以專心致力於完成這篇論文。 感謝各位口詴委員，包括張弘鑫老師、曹孝櫟老師以及林盈達老師，在百忙 之中抽空前來參加我的碩士論文口詴，並提供許多寶貴的意見，特別是曹孝櫟老 師與林盈達老師對於 Linux 及嵌入式系統的開發經驗讓我有更深的體悟。 再來要感謝的是實驗室的學長們，謝謝史永健學長、黃貴笠學長、何承遠學 長、何承運學長等等，在論文及口頭報告上給予我許多建設性的意見，當我遭遇 困難時，學長們總是不吝於給我指導以及方向；感謝同學們：竣晨、坤穎、銘祥、 奕萱、昱樺，無論是在課業或者撰寫論文的過程中，時常給予我精神上的鼓勵， 讓我在交大的生活期間從來不會感到枯燥乏味；感謝學弟妹們的幫忙，讓我能專 心撰寫論文，而不需要煩惱其他的雜事。 最後要感謝我的家人，感謝父母親這兩年來的支持，讓我能夠無後顧之憂， 完成碩士論文，取得碩士學位。

目 錄

摘 要 ...i Abstract ... iii 誌 謝 ... iv 目 錄 ... v 圖 目 錄 ... vii 表 目 錄 ... ix 第一章 緒論 ... 1 1.1 研究動機 ... 1 1.2 研究目標 ... 2 1.3 章節簡介 ... 2 第二章 背景知識介紹 ... 4 2.1 剖析暨除錯技術與相關工具 ... 4 2.2 網路封包擷取工具 ... 7 2.3 Linux 網路封包資料結構 ... 8 2.4 Linux 核心模組... 10 2.5 Linux 使用者空間和核心空間的行程間通訊機制 ... 12 第三章 相關研究 ... 15

3.1 Linux Kernel Profilers ... 15

3.1.1 Linux Trace Toolkit (LTT) [12]~[18] ... 15

3.1.2 Kernprof[19] ... 15

3.1.3 Kernel Function Trace (KFT) [8][20][21] ... 16

3.2 網路通訊協定堆疊之分析 ... 17

3.3 核心行為記錄與網路協定記錄之整倂 ... 18

4.2 系統架構圖 ... 21

4.3 選擇性指令嵌入技術之設計 ... 22

4.3.1 Polymorphism of sk_buff ... 23

4.3.2 Direct / Indirect use of sk_buff ... 25

4.3.3 選擇性指令嵌入技術之架構 ... 26 4.4 封包關聯技術之設計 ... 29 4.5 總結 ... 30 第五章 網路通訊協定堆疊剖析暨除錯工具之實作 ... 31 5.1 實作環境 ... 31 5.2 選擇性指令嵌入技術之實作 ... 31 5.2.1 Polymorphism Module 之實作 ... 31

5.2.2 Direct use function/Indirect use function Module 之實作 ... 33

5.3 封包關聯技術之實作 ... 35 5.3.1 Instrument Module 之實作 ... 35 5.3.2 Log Monitor 之實作 ... 37 5.3.3 Log Matcher 之實作 ... 37 第六章 實驗結果與貢獻 ... 38 6.1 實驗結果分析 ... 38 6.1.1 選擇性指令嵌入技術的實驗結果 ... 38 6.1.2 網路通訊協定堆疊剖析暨除錯工具之網路效能測試 ... 41 6.1.3 核心行為記錄與網路協定記錄之整倂成果 ... 44 6.2 貢獻 ... 46 第七章 結論與未來工作 ... 47 7.1 結論 ... 47 7.2 未來工作 ... 47 Reference ... 49

圖 目 錄

Figure 2-2 網路封包資料結構(struct sk_buff) ... 9

Figure 2-3 驅動程式接收網路封包的流程[46] ... 10

Figure 2-4 Basic Components of relayfs[53] ... 13

Figure 2-5 relayfs 檔案系統之程式範例 ... 14 Figure 3-1 Kernprof 核心函式追蹤畫面 ... 15 Figure 3-2 KFT 核心函式追蹤畫面 ... 16 Figure 3-3 動態指令嵌入平台[48] ... 18 Figure 3-4 核心行為記錄與網路協定行為記錄整倂[59] ... 19 Figure 4-1 論文系統架構圖 ... 21 Figure 4-2 網路封包處理函式(A：全域變數，B：傳遞參數，C：回傳參數，D：區域變 數) ... 23

Figure 4-3 Polymorphism of sk_buff ... 24

Figure 4-4 Multi-level Polymorphism of sk_buff ... 24

Figure 4-5 Indirect use of sk_buff ... 25

Figure 4-6 Multi-level of Indirect Caller ... 26

Figure 4-7 Multi-level of Indirect Callee ... 26

Figure 4-8 選擇性指令嵌入技術之架構 ... 27

Figure 4-9 Pseudo Code of Polymorphism Module ... 27

Figure 4-10 Pseudo Code of Caller ... 28

Figure 4-11 Pseudo Code of Callee ... 28

Figure 4-12 Footprint 之格式... 29

Figure 4-13 KBL 之格式 ... 30

Figure 5-1 Alias 的語法規則 ... 32

Figure 5-4 嵌入指令於函式的結束點 ... 34

Figure 5-5 Kernel Symbol Table ... 35

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

Figure 5-7 Process Context 與 Interrupt Context 的 Race Condition 情形 ... 36

Figure 5-8 Log Matcher 之運作畫面 ... 37

Figure 6-1 驗證選擇性指令嵌入技術 ... 41

Figure 6-2 Iperf 測試之環境配置圖 ... 42

Figure 6-3 TCP 傳輸速率比較於 Memory Logging Disabled ... 42

Figure 6-4 TCP 傳輸速率比較於 Memory Logging Enabled and Disk Logging Disabled ... 43

Figure 6-5 TCP 傳輸速率比較於 Disk Logging Enabled ... 43

Figure 6-6 TCP 傳輸速率比較於 Memory Logging Enabled and Disk Logging Disabled 和 Disk Logging Enabled ... 44

Figure 6-7 TCP 之 Three-way-handshake 測試的環境配置圖 ... 44

Figure 6-8 Three-way-handshake 之 SYN 封包的 PBL... 45

表 目 錄

Table 2-1 現有的剖析暨除錯技術與相關工具 ... 5 Table 2-2 剖析暨除錯技術之優缺點 ... 6 Table 6-1 選擇性指令嵌入技術實驗結果 ... 38 Table 6-2 選擇性指令嵌入技術與其他方法比較結果 ... 38 Table 6-3 選擇性指令嵌入技術與 KLASY 比較結果 ... 40

Table 6-4 Linux Netbook 規格表 ... 41

Table 6-5 Three-way-handshake 之封包的相關資訊 ... 45

第一章 緒論

1.1 研究動機

近年來隨著嵌入式系統(Embedded System)技術的進步與網際網路已大量建 置於生活周遭，使得嵌入式網路通訊裝置也日漸普及，未來再加上雲端計算產業 的發展，裝置連網會更加普遍，如今日已隨處可見的智慧型手機(Apple Iphone、 Google Android)等等。而開發人員為了提升網路通訊裝置的效率、穩定性及安全 性，以及提供使用者更好的服務，花費非常多的努力與時間，開發新且更好的網 路通訊裝置。 然而對一個嵌入式網路通訊裝置而言，無法擁有一般個人電腦的極佳運算能 力及儲存空間。因此開發人員經常關心的是(1)效能問題：如封包傳輸延遲(Packet Delivery Delay)、封包遺漏(Packet Loss)、反應時間(Response Time)，以及(2)系統 內部的除錯問題：如除錯網路通訊協定堆疊的處理過程(Protocol Stack Operation Procedure)。 由於一個嵌入式網路通訊裝置的通訊行為基本上可分為兩大部分：(1)核心 行為，如核心系統內部網路相關元件(Component)的行為、元件之間的訊息交換 (Signaling)等，以及(2)網路協定行為，如：DHCP、TCP、UDP 等，每種網路協 定皆有各自運作的行為。因此通訊裝置的效能與除錯問題會受到使用的網路類 型、核心系統及網路協定等因素，而有所變化。 目前對於網路通訊裝置的通訊行為，仍然沒有一套完整的工具能夠協助開發 者解決效能與除錯問題。網路封包擷取工具(Network Sniffer)取得的網路協定行 為記錄(Protocol Behavior Log, PBL)，僅能協助分析網路協定行為，即網路通訊 裝置的外顯網路封包類型及傳送與接收時間等，對於分析核心系統內部行為的能 力較為缺乏。另一方面，現有的核心系統剖析工具(Kernel Profiler)取得的核心行 為記錄(Kernel Behavior Log, KBL)，雖然可以分析核心系統內部行為，但是無法 正確地分辨出網路封包的傳送與接收過程，而且無法記錄通訊行為分析所需要的 網路封包相關資料。 現有的網路封包擷取工具與核心系統剖析工具也皆未能對應網路協定行為 記錄與核心行為記錄，以取得網路協定行為與核心行為之間的互動與整合效果， 進而剖析暨除錯核心系統的網路通訊協定堆疊。因此本論文著眼於能夠發展一套 針對於網路通訊協定堆疊的剖析與除錯工具，希望能夠彌補目前工具的不足，提 升網路通訊裝置的軟體開發效率與通訊效能。

1.2 研究目標

本論文的研究目標是發展一個網路通訊協定堆疊的剖析與除錯工具，讓嵌入 式網路通訊裝置的開發者可以利用此工具，來剖析與除錯裝置內部的網路通訊協 定堆疊，取得封包處理過程與效能資訊，其中包含有：  封包在網路通訊協定堆疊內部的處理過程  封包傳輸延遲  封包遺漏  反應時間 此外，本論文將加強功能面，以期能達到以下兩大重點：  我們提出一種新的追蹤網路封包處理程序的機制，該機制從核心系統的 原始程式碼中，找出存取封包的函式，並且嵌入指令於該函式，記錄執 行函式與封包相關資訊。之後我們可以藉由函式存取網路封包資料的順 序，來追蹤系統內部處理網路封包的行為與時間點。利用這些記錄，網 路通訊軟體開發者可以很容易分析網路通訊的核心系統行為，釐清與改 善網路通訊的問題，藉此全面剖析與除錯網路通訊協定堆疊。  我們提出一種新的網路通訊裝置之整體通訊行為的分析方法，將核心行 為記錄與網路協定行為記錄作對應，解決現有的核心行為記錄與網路協 定記錄無法整倂的問題，讓開發者可以進一步分析核心運作與網路封包 傳遞之間的互相影響，清楚瞭解且分析網路通訊裝置的整體通訊行為。

1.3 章節簡介

本篇論文的章節編排與內容簡介如下： 第一章：緒論，介紹本論文的研究動機，以及期望能達成的目標。 第二章：背景知識介紹，介紹本論文所應用到的相關知識，主要是針對核心 剖析技術與 Linux 相關的知識，包括網路封包資料結構、核心模組、使用者空間 與核心空間的行程間通訊機制。

第三章：相關研究，介紹與本論文主題相關的工具及文獻，包含現有的核心 剖析工具、網路通訊協定堆疊之分析以及核心行為記錄與網路協定記錄之整倂的 文獻，其中包含本實驗室先前已發展的分析工具。 第四章：網路通訊協定堆疊剖析暨除錯工具之設計與架構，分別說明本論文 所提出的兩種技術：選擇性指令嵌入與封包關聯技術，與其中的設計與架構 第五章：網路通訊協定堆疊剖析暨除錯工具之實作，分別說明本論文所提出 的兩種技術之實作細節，以及其中針對於 Linux 核心系統所作的修改部分。 第六章：實驗結果分析及貢獻，介紹本工具效能評估的實驗結果分析以及整 體貢獻 第七章：結論與未來工作，總結本論文的結果，以及未來可繼續研究的方向。

第二章 背景知識介紹

2.1 剖析暨除錯技術與相關工具

由於現在的系統越來越複雜，因此效能微調與除錯在系統設計中，占有非常 重要的角色[1][2][3][4][5]。了解現有的剖析暨除錯技術與相關工具對於系統設計 可以提供很多的幫助。現有的剖析暨除錯技術根據運作模式，大略可以分成三種 類型：(1)Source Instrumentation、(2)Binary Instrumentation 與(3)Statistical

Sampling，以下介紹剖析暨除錯技術的三種類型：

 Source Instrumentation 運作模式為修改系統原始程式碼，將指令嵌入於 系統原始程式碼，達成搜集系統運作過程的效能與執行流程等等資訊， 利用於剖析與除錯。

 Binary Instrumentation 運作模式為修改系統 Object Code，將指令嵌入於 Object Code，與 Source Instrumentation 類似。然而根據修改 Object Code 的時機點，更可以將之細分成(1)靜態型(Static)與(2)動態型(Dynamic)兩 種。靜態型為系統於執行前，就已經修改系統的 Object Code，執行之 後即不再改變。而動態型為系統於執行的時候(Runtime)，修改已經處 於記憶體內部的系統 Object Code，並不是改變實體的系統 Object Code。由於現有採用 Binary Instrumentation 技術的相關工具主要是動態 型，因此之後章節提到的 Binary Instrumentation 皆是指動態型。  Statistical Sampling 運作模式為利用一個監控程式，每隔一段固定時

間，監看目前 CPU 正在執行的 Instruction，統計系統執行過程中的每一 個 Instruction 或者函式執行的總次數與時間長度。

而相關工具根據剖析暨除錯的對象也可以分成兩種類型：(1)User Level 與 (2)Kernel Level。User Level 剖析與除錯工具的主要對象為運作於 User Space 的應 用程式，如 Firefox 等等。

目前常見的 User Level 相關工具及其研究為 GNU gprof[1][3][6]、 Valgrind[7]、GCC function instrumentation[3][8]、PinOS[9]、GDB(GNU Debugger)[1][10]與 DPCL[11]等等。

Kernel Level 剖析與除錯工具的主要對象為運作於 Kernel Space 的系統程 式，如 Linux 核心系統與所有 Linux 核心模組。因為本論文的主要剖析與除錯對 象為核心系統，之後我們將探討 Kernel Level 剖析與除錯工具。

Table 2-1 現有的剖析暨除錯技術與相關工具

Approach

Tool

Source Instrumentation

Linux Trace Toolkit (LTT)[12]~[18] Kernprof[19]

Kernel Function Trace (KFT)[8][20][21] Kernel Tuning and Analysis Utilities (KTAU)[22][23]

Linux Kernel State Tracer (LKST)[24]

Binary Instrumentation

Kprobe[25][26][27][28] SystemTap[29][30][31][32] KernInst[33][34][35]

Kernel Level Aspect-oriented System (KLASY)[36][37]

DTrace (Solaris-Based)[38] Statistical Sampling Oprofile[39][40][41]

每一個 Kernel Level 剖析暨除錯工具都有其特定之目的：  LTT、KTAU 與 LKST

主要適用於觀察核心系統整體行為，如：Average Load、Context Switch、 Send Signal、Interrupt、Exception、Memory Allocation、網路封包傳送與接 收等等行為；

 Kernprof 與 KFT

主要適用於觀察核心系統全部函式的執行過程，讓使用者觀察完整的核 心函式 Call Graph；

 Kprobe、KernInst 與 DTrace

選擇且動態地嵌入指令於任何位置的 Object Code，取得剖析與除錯所需相 關資訊。然而使用 Dynamic Binary Instrumentation 的機制時，使用者必頇藉 由 Compiler 或者 Disassembler 的協助，事先取得目標指令(Instruction)的記 憶體位址，才能動態地嵌入指令於目標指令；  SystemTap 主要是提供一個使用介面給使用者，讓使用者藉由 SystemTap 簡化使用 Kprobe 的困難處。使用者僅需要提供目標的函式名稱，SystemTap 負責尋找 目標函式的記憶體位址，並且完成設定 Kprobe；  KLASY 與 SystemTap 的目的相同，主要提供一個使用介面給使用者，讓使用者 藉由 KLASY 簡化使用 KernInst。與 System 的不同點在於使用者可以提供目 標的資料結構名稱，KLASY 則負責尋找核心內部中，所有處理目標資料結 構的指令(Instruction)的記憶體位址，並且完成設定 KernInst；

 Oprofile

主要是利用 CPU 內建的 Performance Counter，每間隔一段時間產生 timer interrupt，週期性監測 CPU 目前正執行的指令(Instruction)。以統計方 式，剖析核心系統行為，讓使用者觀察到巨觀的核心系統行為。

以上提到的所有工具中，與本論文的目標最為相近的是 KLASY。但 KLASY 使用 Binary Instrumentation，因此核心系統必頇先經由特定的 Compiler 編譯，以 及必頇執行於特定的裝置。而且 KLASY 的剖析層面深入到指令(Instruction)，達 成精細(Fine-grained)的剖析程度，但是也使得產生的剖析資料過於龐大，對於嵌 入式裝置的開發者相當不方便。而本論文的選擇性指令嵌入技術，只記錄存取網 路封包的函式與封包相關資訊。 現有的 Kernel Level 剖析暨除錯工具，已經提供許多功能強大的剖析與除錯 功能。但是只能剖析核心系統內部行為，無法正確地分辨出網路封包的傳送與接 收過程。而且無法記錄通訊行為分析所需要的網路封包內容資料，未能整倂核心 行為記錄與網路協定記錄，進而剖析暨除錯核心系統的網路通訊協定堆疊。 因此本論文無法利用現有的工具達成目標，我們必頇針對網路通訊協定堆疊 開發一套剖析暨除錯工具。所以我們將剖析暨除錯技術的優缺點[1][2][3]整理成 Table 2-2，選擇適合本論文的剖析暨除錯技術： Table 2-2 剖析暨除錯技術之優缺點

Approach Advantage Drawback

Source Instrumentation

Less Impact Recompilation, Reinstallation, Rebooting More Portable

Binary Instrumentation

No Source Code Required Reverse Engineering

No Recompilation Instruction Set Architecture (ISA) Dependence

Statistical Sampling

Low Overhead Statistical Approximation Program Changeless OS and ISA Dependence Source Instrumentation 的優點有：(1)與 Binary Instrumentation 相比，對系統 的影響比較小(Less Impact)，(2)不需要依靠特定裝置，因此可移植性很高(More Portable)，(3)容易達成專門的需求(Flexible)。另一方面，缺點是需要重新編譯系 統原始程式碼，重新安裝系統，重新啟動系統。

Binary Instrumentation 的優點有：(1)不需要系統的原始程式碼(No Source Code Required)，(2)不需要重新編譯系統原始程式碼(No Recompilation)。另一方 面，缺點有：(1)需要事先藉由 Compiler 或者 Disassembler 的協助，取得目標函 式的記憶體位址(Reverse Engineering)，(2)需要依靠特定的 CPU 指令集(ISA Dependence)。

Statistical Sampling 的優點有：(1)對於系統的負擔很低(Low Overhead)，(2) 不需要修改系統(Program Changeless)。另一方面，缺點有：(1)得到的剖析結果為 統計的近似值(Statistical Approximation)，而不是精準的數值，(2)需要依靠特定的 作業系統與 CPU 指令集(OS and ISA Dependence)。

因為本論文的目標是剖析暨除錯嵌入式網路通訊裝置核心系統內部的網路 通訊協定堆疊，然而嵌入式網路通訊裝置的 CPU 架構非常多樣化。如果我們選 用 Binary Instrumentation，則需要針對每一種 CPU 架構調整本論文的工具。而且 我們需要觀察且記錄詳細的通訊行為，如果使用 Statistical Sampling，則無法得 到精準的數值。另一方面，使用 Source Instrumentation 可以輕易達成本論文的目 標，針對存取網路封包的函式(Procedure Level)，因此只需要粗糙(Coarse-grained) 的剖析程度，藉此縮小核心行為記錄，方便開發者使用。

結論是 Source Instrumentation 具有以下優點：(1)對系統運作行為的影響較少 (Less Impact)，(2)移植性高(More Portable)，及(3)可特製需求(Flexible)。因此我 們採用 Source Instrumentation 實現本論文所提出的工具，在本論文的第三章，我 們將會進一步地探討採用 Source Instrumentation 的剖析與除錯相關工具。

2.2 網路封包擷取工具

網路封包擷取工具(Network Sniffer)具有其他意義相近的名稱，如：網路封 包過濾器(Packet Sniffer)、網路分析器(Network Analyzer)、通訊協定分析器

(Protocol Analyzer)等等。主要的目的是在特定網路之中，擷取所有的網路封包並 且記錄網路封包的相關資訊，如：封包的到達時間(Arrival Time)、擷取封包的大 小等等。於擷取完成之後，解析所有封包，針對每一個封包的內容依據對應的通 訊協定格式，如 Figure 2-1。 時間資訊 封包大小等資訊 TCP解析結果 Figure 2-1 網路封包擷取工具使用畫面[42] 目前的網路封包擷取工具已經相當成熟，主要的對象包含有 Ethernet 有線網 路封包、802.11 無線網路封包等等。因此無論是 Link Layer、Network Layer 或者 Transport Layer 的網路封包，皆可以利用相對應的網路協定解析所有的內容。在 Linux/Unix 平台中，網路封包擷取工具大多數是利用封包擷取函式庫(Libpcap) 為基礎，達成擷取與過濾(Filter)的目的，如：Ethereal/Wireshark[42]、Kismet[43]、 tcpdump[44]等等。 儘管網路封包擷取工具功能非常強大，但是也僅能分析網路通訊裝置的外顯 網路封包類型及傳送與接收時間等等。對於分析核心系統內部行為的能力較為缺 乏，無法剖析暨除錯核心系統的網路通訊協定堆疊。

2.3 Linux 網路封包資料結構

Linux 核心系統本身的網路功能已經相當成熟，也支援大多數的網路通訊協 定，而且 Linux 擁有開放原始程式碼(Open Source)的特性，因此我們可以很容易 地觀察核心系統內部的原始程式碼，比如：核心系統內部的資料儲存結構、網路 通訊裝置輸入與輸出(Device I/O)行為，核心系統中斷(Interrupt)機制等等。

Linux 核心系統內部有一個重要的網路封包資料結構 struct sk_buff[45]，當網 路封包在網路通訊協定堆疊的處理過程中，struct sk_buff 用於儲存網路封包內容 的記憶體位址與管理網路封包的相關資訊，如 Figure 2-2。Packet data storage 即 為實體儲存網路封包內容的記憶體空間，而 Management Data 即為 struct sk_buff

資料結構，其中最重要的資訊為儲存網路封包內容的記憶體位址與網路封包的長 度(如 head、data、tail、end 和 len 等)，說明如下：

head 和 end 皆為指標，指向可以被用於儲存網路封包內容的記憶體空間； data 和 tail 也皆為指標，指向目前已經儲存網路封包內容的記憶體空間；len 為

目前已經儲存網路封包內容的總長度。網路通訊協定堆疊中的每一個網路通訊協 定可以利用這些指標與長度資訊操作網路封包內容，輕易地增加或刪去封包的 Protocol Header，讓封包在每一層網路通訊協定傳遞時，不需要重新分配記憶體 空間及重複地複製封包內容，造成空間和時間的浪費，因此一個 struct sk_buff 將會對應於一個網路封包。 其他管理網路封包的相關資訊，如：stamp 為網路封包被網路卡驅動程式傳 送或者接收的時間點；dev 為網路封包傳送或者接收的網路裝置介面；h 為指標 指向 Transport Layer 的 Protocol Header；nh 為指標指向 Network Layer 的 Protocol Header；mac 為指標指向 Link Layer 的 Protocol Header。

Figure 2-2 網路封包資料結構(struct sk_buff)

當網路封包從網路上傳送到本機端時，網路介面卡的驅動程式會負責規畫一 個型態為 struct sk_buff 記憶空間，用於儲存接收的網路封包內容，之後網路通訊 協定堆疊就可以開始處理網路封包，而驅動程式接收封包的流程，如 Figure 2-3， 總共分為六個步驟[46]：

1. 驅動程式擁有一個由許多個 Packet Descriptor 組成的 Ring Buffer，而每 一個 Packet Descriptor 則指向一個 struct sk_buff，當網路封包從網路上 傳送到本機端時，網路介面卡利用 Direct Memory Access (DMA)將封包 搬移到驅動程式所規劃的 struct sk_buff。

2. 網路介面卡啟動 Interrupt。

3. 驅動程式的 Interrupt Handler 將儲存網路介面卡相關資訊的資料結構

半部處理(Softirq)。

4. Softirq 檢查 Poll_queue 中，目前有哪些網路介面卡擁有網路封包需要接 收。

5. Softirq 向驅動程式要求 struct sk_buff。

6. 驅動程式將 struct sk_buff 從 Ring Buffer 移除後，再傳遞給 Softirq，並 且重新規劃一個 struct sk_buff 放回 Ring Buffer。

Figure 2-3 驅動程式接收網路封包的流程[46] 至於網路封包從本機端傳送到網路上的流程大致與接收的流程相同，將不再 贅述，由以上所述，我們可以知道 struct sk_buff 對於網路通訊協定堆疊的運作是 非常重要的。因此本論文得以提出選擇性指令嵌入技術，利用 struct sk_buff，從 核心系統的原始程式碼中，找出存取網路封包的函式，並且嵌入指令，記錄處理 封包的核心函式執行順序與封包關聯技術所需的封包相關資訊，幫忙開發者排除 問題或找出網路通訊協定堆疊的效能瓶頸。

2.4 Linux 核心模組

Linux 核心系統是由一個基礎的核心(Base Kernel)與許多的核心模組(Linux Kernel Module)所組成，基礎核心指的是裝置啟動時需要的基本系統功能，因此 在使用者編譯基礎核心時，必頇將裝置啟動所需的功能，內建(Build-in)於基礎核 心之中，而核心模組指的是即為未來可以動態載入的 Linux 核心模組。 當初的發展動機是在於若所有裝置的驅動程式(Device Driver)都事先內建於 核心系統之中，則核心系統的規模會非常大，對於裝置的儲存空間、系統的啟動 效率與記憶體使用率都會造成不良的影響，而且對於編製專屬於某一個裝置的核 心系統非常不方便。因此事先只將核心系統納入最基本的功能，即為基礎核心， 其餘選擇性的功能則改用可以動態載入的核心模組達成。

需要重新編譯基礎核心，所以不會增加基礎核心的規模，也不需重新啟動裝置。 當 Linux 核心系統需要某項功能時，才動態載入對應的核心模組，不需要此項功 能時，則可以卸除此核心模組，讓 Linux 核心系統回復到原始狀態。 目前 Linux 核心模組主要利用於以下六種情形[47][48]： 1. 裝置驅動程式(Device Driver) 一個裝置驅動程式是針對特定的硬體裝置所設計，讓 Linux 核心系統利 用裝置驅動程式與硬體裝置溝通，而不需要了解硬體裝置運作的任何細節。 因此 Linux 核心系統想要使用任何硬體裝置，則必頇擁有該硬體裝置所對應 的裝置驅動程式，如：PCI 裝置有對應的驅動程式，USB 裝置也有對應的驅 動程式。 2. 檔案系統驅動程式(Filesystem Driver) 一個檔案系統驅動程式是針對特定的檔案系統格式所設計，負責解讀檔 案系統的內容，而檔案系統的內容通常是儲存於硬碟的資料，解讀的結果便 是檔案與目錄。目前有許多種儲存檔案與目錄於硬碟的檔案系統格式，常見 的格式有 Windows 系統的 NTFS、FAT 與 Linux 系統的 ext3、ext2，每一種 皆有其對應的檔案系統驅動程式。 3. 系統呼叫(System Call) User Space 的程式可以透過系統呼叫取得核心系統提供的服務，如：存 取檔案、啟動一個新的 Process、關閉核心系統等等，絕大多數的標準系統 呼叫被視為 Linux 核心系統必需的功能。因此內建(Built-in)於基本核心，但 是使用者也可以利用 Linux 核心模組，自行開發系統呼叫。 4. 網路驅動程式(Network Driver) 一個網路驅動程式是針對特定的網路通訊協定所設計，而 Linux 網路通 訊協定堆疊則是由許多個網路驅動程式所組合而成，用於傳送與接收各種網 路通訊協定的網路封包，如：Linux 核心系統想要處理 IPX 的網路封包，則 需要擁有 IPX 的網路驅動程式。

5. TTY 管制線(TTY Line Discipline)

TTY 管制線基本上是裝置驅動程式的擴充，協助裝置驅動程式轉換終 端機裝置(Terminal Device)傳送與接收的資料格式。

6. 執行檔直譯器(Executable Interpreter)

一個執行檔直譯器負責載入與執行一個執行檔，然而執行檔的格式有許 多種，因此每一種格式的執行檔皆需要對應的執行檔直譯器，才能讓執行檔 執行於 Linux 核心系統，而 Linux 核心系統中，最常見的是 ELF (Executable and Linkage Format)格式。

由於本論文需要取得核心系統與網路協定互動的相關重要資訊，諸如時間標 記(Timestamp)、封包相關資訊和核心函式執行順序等等，而且我們希望降低本 論文對於原始 Linux 核心系統的影響。因此我們利用 Linux 核心模組的動態載入 特性，當載入 Linux 核心模組時，才開始記錄核心行為，記錄完畢之後，卸載 Linux 核心模組，讓 Linux 核心系統回復到原本的狀態。

2.5 Linux 使用者空間和核心空間的行程間通訊機制

Linux 透過權限管理，將之區分成使用者空間(User Space)與核心空間(Kernel Space)，使用者執行的應用程式運行於使用者空間，而核心系統則是運行於核心 空間，彼此之間不能直接存取記憶體。因此由核心系統提供訊息溝通機制，讓應 用程式與核心系統之間可以交換訊息，常見的溝通機制有：ioctl[49][50]、 Netlink[51]、procfs[1]、Memory MAP[49]、relayfs[52][53]。

ioctl 為 Input/Output Control，主要目的是讓應用程式透過 ioctl 傳送命令給核 心系統，而核心系統會根據命令，執行相對應的動作，最後將結果回傳給應用程 式。許多網路管理程式即是透過 ioctl 控制核心系統，如：iptable、ifconfig、iwconfig 等等。

Netlink 為一種 Linux 特有的 Socket，讓應用程式與核心系統具有連線的狀 態，與其他的行程間通訊機制相比，Netlink 的優勢是可以讓使用者空間和核心 空間進行雙向的資料傳輸，而不僅是核心空間對於使用者空間的請求回應相對訊 息，所以核心系統可以主動傳輸訊息給應用程式。

procfs 為 Process File System，一個虛擬檔案系統(Virtual File System)，核心 系統利用檔案的方式，讓應用程式取得核心系統內部的資訊，如：記憶體使用狀 態、CPU 的資訊等等。虛擬檔案與一般檔案的不同點在於虛擬檔案的資訊是儲 存於核心空間的記憶體，所以當應用程式讀取虛擬檔案時，核心系統直接將資訊 從核心空間複製到使用者空間，讓應用程式得以取得資訊。但是 procfs 並未提供 應用程式存取虛擬檔案所需的處理函式(Handler Function)，因此使用者必頇自行 撰寫處理函式，不方便使用者使用。

Memory MAP (MMAP)為一個記憶體映射機制，由於應用程式的記憶體空間 (Process Address Space)為虛擬記憶體位址(Virtual Memory Address)，無法直接存 取核心空間的記憶體位址。所以 MMAP 將核心系統內部的一塊記憶體空間對映 到應用程式的記憶體空間，讓應用程式得以直接存取核心空間的記憶體位址，進 而取得核心系統內部的資料，不需要執行額外的複製動作。但是應用程式存取核 心空間的內部資料時，必頇特別注意應用程式之間或中斷環境(Interrupt Context) 與程序環境(Process Context)之間是否會發生 Race Condition。然而 MMAP 並未 提供上述問題的解決方法，因此 MMAP 對於本論文需要取得大量且精確的資料 是不方便使用的。

relayfs 為 Data Relay File System，與 procfs 相同也是一個虛擬檔案系統，但 是 relayfs 的目的為提供一個高效率的資訊傳輸機制，用來傳輸大量且持續的串 流資料從核心空間到使用者空間。relayfs 的架構圖如 Figure 2-4，relayfs 為每一 個 CPU(cpu0)各自配置一塊記憶體空間(kbuf0)，並將 kbuf0 對應到一個管理檔案 的資料結構(/cpu0)，核心系統則利用 relay_write 將資訊寫入 kbuf0。當 relayfs 被 掛載(Mount)時，才產生虛擬檔案(/mnt/cpu0)於 User Space，因此應用程式才得以 使用 MMAP 存取/mnt/cpu0，將大量且持續的串流資料傳輸到 User Space。relayfs 的設計架構可以避免多處理器的應用程式之間發生 Race Condition。另一方面， 雖然 relayfs 利用 MMAP，但是內部已經實作相關程式，避免發生中斷環境與程

序環境之間發生 Race Condition 的問題，確保資料的正確性。因此我們可以利用 relayfs 達成本論文需要取得大量且精確的資料的目的。

Figure 2-4 Basic Components of relayfs[53]

relayfs 更提供存取檔案所需的處理函式(Handler Function)，因此當使用者在 使用 relayfs 時，不需要自行撰寫處理函式。User Space 的應用程式只需要利用存 取檔案的相關系統呼叫(System Call)，如：read、write 等等，即可存取 relayfs 的 虛擬檔案。

relayfs 的使用方法與 procfs 相類似，通常使用者利用 Linux 核心模組可動態 載入的特性，當載入核心模組時，才配置記憶體空間與產生相關的虛擬檔案。因 此 relayfs 的使用方法大多數是以核心模組的方式撰寫而成，如 Figure 2-5。

Figure 2-5 relayfs 檔案系統之程式範例

Figure 2-5 為一個標準的 Linux 核心模組程式架構，包括必要的標頭檔案 module.h 和 kernel.h，以及模組的初始化函式 init_module、結束函式 cleanup

module。因為我們將以核心模組的方式來產生 relayfs 的虛擬檔案，所以必頇引

入 relayfs 的標頭檔案 relay.h。之後於核心模組的初始化函式 init_module，執行 relayfs 提供的函式 relay_open，配置記憶體空間與產生虛擬檔案，而 relay_open 的回傳值即為管理此檔案的資料結構 struct rchan。最後於核心模組的結束函式

cleanup_module，執行 relayfs 提供的函式 relay_close，釋放記憶體空間與虛擬

檔案，達成動態產生虛擬檔案的目的。 #include <linux/module.h>

#include <linux/kernel.h>

#include <linux/relay.h> /*Necessary when using the relayfs*/ static struct rchan * chan;

int init_module(void) {

chan = relay_open("cpu", dir, subbuf_size, n_subbufs, &relay_callbacks); if(!chan) {

printk(KERN_ALERT "Couldn't create relay channel.\n"); return -ENOMEM; } return 0; } void cleanup_module(void) { if(chan) { relay_close(chan); chan = NULL; } }

第三章 相關研究

3.1 Linux Kernel Profilers

現有的 Linux Kernel Profilers 非常多，因此本節將只介紹與本論文相同採用 Source Instrumentation 的代表性工具：Linux Trace Toolkit (LTT)[12]~[18]、 Kernprof[19]和 Kernel Function Trace (KFT) [8][20][21]。

3.1.1 Linux Trace Toolkit (LTT) [12]~[18]

LTT 手動嵌入指令於 Linux 核心系統內部的各種重要核心事件觸發點，以剖 析整體 Linux 核心系統的運作行為，例如：中斷、排程和記憶體存取等等。但是 對於剖析網路通訊協定堆疊行為，LTT 僅嵌入指令於傳送網路封包與接收網路封 包的核心事件觸發點，因此使用者只能得知核心系統傳送與接收封包的動作，無 法詳細追蹤網路封包於網路通訊協定堆疊內部的處理過程。而且 LTT 為使用手 動方式嵌入指令，所以 LTT 提供幾乎所有版本 Linux Kernel Patch[18]，讓 LTT 支援所有版本 Linux Kernel。但是嵌入式系統並不只有 Linux 而已，所以 LTT 並 不方便系統開發者使用。

3.1.2 Kernprof[19]

Kernprof 利用 Gcc Compiler 提供的-pg 選項，自動嵌入指令於每一個核心函 式，並且給予一個編號。在系統運作的期間，記錄每一個函式被呼叫的次數與運 作時間，以及每一個函式與呼叫該函式/被該函式呼叫的函式(Parent/Child)之間的 關連，產生所有函式的 Call Graph，如 Figure 3-1。

Parent

Primary Function Child

Figure 3-1 Kernprof 核心函式追蹤畫面

圖中每一個使用長虛線間隔的區塊，代表一個主要函式(Primary Function)的 Call Graph。位於 Primary Function 之上的函式皆為此 Primary Funciton 的 Parent，

位於 Primary Function 之下的函式皆為此 Primary Function 的 Child。其中的數據： index 指 Kernprof 給予 Primary Function 的編號、%time 指 Primary Function 的使 用時間比、self 指 Primary Function 的總運行時間、children 指 Primary Function 呼叫 Child 的總運行時間、called 指被呼叫的總次數、name 指函式的名稱及編號。

使用者可以藉由 Kernprof 的分析結果得到核心系統內部所有函式之間的關 聯性，並且剖析核心系統的效能。但是使用者依然無法藉由此分析結果，進而有 效率地且正確地分辨出處理封包的核心函式執行順序，如 Figure 3-1。圖中橢圓 虛線所指的 do_softirq 為與網路封包處理過程無關的函式。除非使用者事先追蹤 過 Linux 網路通訊協定堆疊的原始碼，或者研究有關 Linux 網路通訊協定堆疊的 書籍，否則無法判斷。 而且 Kernprof 對於核心系統效能剖析的準確度稍微不足，Kernprof 只能提供 到 0.01 s 的準確度，網路通訊協定堆疊中的網路封包處理函式通常都需要達到 µs 的準確度，因此 Kernprof 無法達到詳細剖析網路封包於網路通訊協定堆疊內部 的處理效能。

3.1.3 Kernel Function Trace (KFT) [8][20][21]

KFT 與 Kernprof 類似，KFT 利用 Gcc Compiler 提供-finstrument-functions 選項，自動嵌入指令於每一個核心函式，完整取得核心系統中核心函式的運行過 程，如 Figure 3-2。其中：Entry 指進入該函式的時間點，Delta 指該函式的運行 時間，如第一個函式_local_bh_enable，運行時間為 1µs，PID 指該函式運行時的 Process ID，PID 為-1.0 表示核心系統，Function 指該函式的名稱，Caller 指呼叫 該函式的函式名稱。使用者可以利用 KFT 的結果，詳細觀察核心系統中所有的 函式，並且取得每一次函式執行時間，準確度高達 µs，對於分析核心系統的效 能瓶頸很有幫助。 Figure 3-2 KFT 核心函式追蹤畫面 但是 KFT 與 Kernprof 擁有相同問題，使用者無法藉由 KFT 的分析結果，有 效率且正確地分辨出處理封包的核心函式順序，如 Figure 3-2，圖中橢圓虛線所 指的_local_bh_enable、do_softirq 與 smp_apic_timer_interrupt 即為與網路封包存 取無關的函式。 KFT 與 Kernprof 除了無法正確地分辨處理封包的核心函式執行順序之外， KFT 與 Kernprof 利用 compiler 自動嵌入指令於每一個核心函式，雖然可以得到 非常細部的核心系統行為，但是對於核心系統產生的負擔也很大，從 KFT 的文

件[8]中，可以得知 KFT 在 Communication 的 overhead 高達 600~1000%，因此對 於網路通訊協定堆疊無法得到精準的剖析結果。 另一方面，LTT、KFT 與 Kernprof 都無法記錄本論文中封包關聯技術所需要 的封包相關資訊，因此無法取得某一封包於核心系統的處理過程與時間點，也無 法幫忙開發者排除問題或找出網路通訊協定堆疊的效能瓶頸。

3.2 網路通訊協定堆疊之分析

網路通訊協定堆疊之分析的議題[54][55][56]已被探討很久，除了 3.1 節所介 紹的 Linux Kernel Profiler 之外，另有許多論文[37][46][48][57][58]以此為方向進 行研究，本節將探討與本論文的研究目標相吻合的相關論文。

 A dynamic aspect-oriented system for OS kernels[37]

Yanagisawa, etc.提出一個技術-KLASY，目標為簡化使用 KernInst[34]會遭遇 到的困難處。使用者使用 KernInst 時，需事先取得目標指令(Instruction)的記憶體 位址，才能設定 KernInst 動態地嵌入指令於目標指令。使用者使用 KLASY 時， 只需提供目標資料結構的名稱，KLASY 負責找出目標資料結構被處理的指令位 址，並且完成設定 KernInst[34]且嵌入指令。該論文以網路通訊堆疊之剖析為例 子，但是 KLASY 所產生的分析資料過於龐大，使用者無法有效率地追蹤處理封 包的核心函式執行順序，且此技術需要特定的編譯器(Compiler)協助，對於嵌入 式裝置的開發者相當不方便。

 The performance analysis of linux networking - Packet receiving[46]

Wenji Wu, etc.事先追蹤 Linux 核心程式碼之後，將 Linux 系統接收網路封包 的過程分為三個階段，分別依序為 NIC & Device Driver、Kernel Protocol Stack 和 Data Receiving Process，並且手動嵌入指令於這三階段的部分函式內，探討內 部的運作過程，以及取得實驗結果。雖然該論文並未詳細分析封包於這三階段的 內部處理程序，但是找出其中的重要函式，因此本論文將會比較選擇性嵌入指令 與該論文兩者找出的函式，以驗證選擇性嵌入指令的功能。

 Design and Implementation of an Efficient and Configurable Instrument

Platform for Linux Network Protocol Stack[48]

該論文為本實驗室的曹敏峰所提出的，作者手動嵌入指令於 Linux 網路通訊 協定堆疊中的每個重要函式，目標是分析 Linux 核心系統行為以及獲得網路通訊 協定與 Linux 核心系統互動的相關重要資訊。 然而作者認為如果嵌入直接記錄資訊的指令於核心系統之中，缺點在於如果 使用者想要變更記錄的資訊時，則必頇重新嵌入指令，重新編譯系統以及重新啟 動系統。因此為了改善此缺點，作者設計一個動態指令嵌入平台(Configurable Instrument Platform)，如 Figure 3-3。於此平台之中，事先嵌入於核心系統程式碼 內部的指令，只是讓核心系統轉移控制權以及傳遞資訊的指令(Probe)。因此當核 心系統執行到 Probe 時，即將控制權轉移到核心模組(Kernel Module)，讓核心模

組之中的記錄資訊指令，真正地記錄資訊，藉此達成動態的指令嵌入功能。

outputFunc{

record information;

}

Kernel Module

Patched Source Code

Probe C Probe B Probe A Figure 3-3 動態指令嵌入平台[48] 該論文的實驗結果顯示此平台可以有效率地取得核心系統行為以及封包相 關的重要資訊，但是由於該論文只嵌入指令於網路通訊協定堆疊中的重要函式。 因此無法取得封包的詳細處理程序，所以該論文還是不足以完整分析網路通訊協 定堆疊。本論文參考該論文的方法然後加上與網路協定行為記錄整倂的結果。

3.3 核心行為記錄與網路協定記錄之整倂

 Application-Specific Packet Capturing using Kernel Probes[28]

Byungjoon Lee, etc.提出一個工具，目標為擷取特定應用程式所傳送與接收 的網路封包，利用 Kprobes[25]於 Linux 核心系統內部取得處理網路封包的 Process 名稱與封包的 5-tuple 資料，最後對應系統內部取得的資料與 Sniffer 擷取的網路 協定行為記錄，即可篩選出特定應用程式所傳送與接收的網路封包。該論文的實 驗結果顯示篩選準確度很高，但是其目的為完整取得特定應用程式傳送與接收的 網路封包，只需要封包的 5-tuple 即可，然而卻無法涵蓋所有網路協定，如：ICMP、 ARP 等，因此無法分析 Linux 整體通訊行為。

 Design and Implementation of a Networking Behavior Analysis Tool for

Linux Operating System[59]

該論文為本實驗室的徐勝威所提出的，目標是設計一套網路通訊裝置的評比 工具，分析與衡量網路通訊裝置的通訊行為，協助開發者尋找網路通訊裝置的效 能瓶頸。此工具分析的通訊行為包括：網路封包在核心系統內部的傳輸/接收過 程、網路封包傳送/接收時的延遲、IP address 的取得和 Routing Table 的變化。該 論文整倂核心行為記錄與網路協定記錄，來達成分析與衡量通訊行為的目標。

於該論文中，整倂核心行為記錄與網路協定記錄時，利用以下總共七項資訊 作為參考點，如 Figure 3-4：

 Ethernet MAC Header：

(1)Destination MAC Address、(2)Source MAC Address、(3)Type  IP Header：

(4)Destination IP Address、(5)Source IP Address、(6)Identification  (7)網路封包的長度(Packet Length)

Figure 3-4 核心行為記錄與網路協定行為記錄整倂[59]

然而該論文所提出的整倂參考點並不是全部皆為必要的資訊，如網路封包的 長度資訊對於整併是不必要的，因為有些控制類型的網路封包長度是固定的，比 如 TCP 的 SYN，所以整倂此類網路封包不必要使用長度資訊。另一方面，對於 Transport Layer 以上的網路協定封包，Ethernet MAC Header 的資訊是不必要的。

而且也有不足的部分，如缺少 IP Header 的 Protocol 欄位。我們從 RFC 791[60] 得知：在一段時間內，一對 Source 和 Destination 的同一種網路協定連線中，IP Header 的 Identification 必頇為唯一的。因此該論文只利用 IP Header 的 Source IP、 Destination IP 與 Identification 是不夠的，需要再加入 Protocol 以驗證 Identification 於不同網路協定連線之間重複的情況。

上述論文主要於整倂核心行為記錄與網路協定記錄，各自有各自的考量與方 法。本論文的目標為利用最少資訊於整倂核心行為記錄與網路協定記錄，協助開 發者正確界定造成網路封包延遲與遺漏的原因，進而分析問題及改善缺失。

第四章 網路通訊協定堆疊剖析暨除錯

工具之設計與架構

本章將介紹本論文中的網路通訊協定堆疊剖析暨除錯工具。首先會介紹此工 具的設計概念及設計目標，再來介紹完整的系統架構，最後介紹本工具所提出的 技術，及其中的每一個元件(Component)。

4.1 設計概念與目標

網路通訊協定堆疊剖析暨除錯工具主要的用途是剖析暨除錯嵌入式網路通 訊裝置核心系統內部的網路通訊協定堆疊，本工具透過指令嵌入技術取得核心系 統與網路協定互動的相關重要資訊，諸如時間標記(Timestamp)、網路封包相關 資訊和核心函式執行順序等等。之後將取得的核心行為記錄(Kernel Behavior Log, KBL)，與網路封包擷取工具取得的網路協定行為記錄(Protocol Behavior Log, PBL)進行整倂，即可剖析暨除錯核心系統內部的網路通訊協定堆疊，更能進一 步地分析網路封包傳送與接收過程的效能。

本工具的主要目標是從核心系統原始程式的執行過程之中，去剖析暨除錯網 路通訊協定堆疊的運作，然而原始程式非常龐大且牽涉到太多與網路通訊協定無 關的處理，因而提出兩個方法來找出相關程式片段。此兩方法為選擇性指令嵌入 (Selective Instrumentation)與封包關聯(Packet Association)技術。

選擇性指令嵌入技術即是將指令嵌入於系統中的原始程式碼，因此產生兩種 實作方式：手動(Manually)或自動(Automatically)，於 3.1 節介紹的 LTT 與 3.2 節 介紹的動態指令嵌入平台[48]是使用手動方式。另一方面，於 3.1 節介紹的 KFT 與 Kernprof 是使用自動方式，但是這四者都無法達到本工具的目標。 由於核心系統版本一直更新與改變，連帶改變核心系統內部的核心行為，因 此網路封包處理路徑也有可能改變，封包處理路徑的改變有可能是因為封包處理 函式增加或者減少。如果我們選用手動方式將指令嵌入於核心系統的原始程式 碼，則需要仿效 LTT 提供所有版本 Linux Kernel Patch，讓本工具達到對於 Linux Kernel 的高支援度。然而提供所有版本 Linux Kernel Patch，則需要耗費許多人力 去檢驗以及嵌入指令於所有版本 Linux Kernel。所以使用手動方式以達成本工具 的目標是非常沒有效率且容易出錯，因此我們決定採用自動方式，期望得出一個 方法，達成自動嵌入指令於核心系統的封包處理函式。 封包關聯技術是為取得核心行為與網路協定行為之間的互動與整合效果，以 剖析暨除錯核心系統內部的網路通訊協定堆疊，而現有的核心系統剖析工具與網 路封包擷取工具應用於整倂 KBL 與 PBL 有以下缺點：  核心系統剖析工具通常未考量與網路協定記錄整倂，因此取得的 KBL

因此無法整倂核心行為記錄與網路協定記錄。  網路封包擷取工具取得的 PBL，通常只有完整的封包內容與擷取到網路 封包時的時間標記(Timestamp)，如 Figure 2-1。然而在網際網路環境之 下，我們必頇考慮到網路封包擷取工具與核心系統剖析工具為各自獨立 的事實，因此 KBL 與 PBL 之間會有些許的時間差，所以時間標記不適 合作為整併的依據。 因此我們期望改進上述的缺點，達成整倂核心行為記錄與網路協定行為記錄 為目標。由於網路協定記錄已經包含有完整的封包內容，因此我們僅需要從核心 系統內部取得封包的相關資訊，即可作為整併的參考點。本技術則希望於不影響 核心系統運作的行為情況之下，從核心系統內部取得最少的封包相關資訊，達成 整倂 KBL 與 PBL 的目標。

4.2 系統架構圖

Figure 4-1 是本論文所提出的系統架構圖：

Selective Instrumentation Unit

Polymorphism

Direct use

function

Indirect use

function

Instrument

Criteria

(

struct sk_buff

)

Network

Device

User Space Kernel Space (Patched Kernel) Transport Layer Network Layer Link Layer

Physical Network

Instrument

Module

Memory

Log

Monitor

KBL

_{PBL Monitor}

Device

Network

Sniffer

Analyzer Unit

Log

Matcher

Integrated

Viewer

Original

Kernel

Figure 4-1 論文系統架構圖

Figure 4-1 中主要有兩大部分：

 選擇性指令嵌入(Selective Instrumentation Unit)技術

本技術利用原始核心系統程式碼(Original Kernel)中，與網路封包處理相 關的資料結構 struct sk_buff 作為尋找的基準點(Instrument Criteria)，先利用 Polymorphism Module 找出所有 struct sk_buff 的變形，再利用 Direct use function Module 與 Indirect use function Module 找出原始核心系統內部實質 處理網路封包之函式，並且將剖析與除錯指令自動嵌入於函式內，以產生嵌 入剖析與除錯指令的核心系統程式碼。我們編譯已經嵌入指令的核心系統程 式碼，產生修改過的核心系統(Patched Kernel)並且將之安裝於 Network Device。

 封包關聯(Packet Association)技術

本技術設計被嵌入的指令必頇記錄的最少封包相關資訊及它經過處理 函式的順序與時間點，此記錄稱之為 KBL。我們將實際記錄資訊的指令實 作於 Instrument Module，讓 Instrument 先將 KBL 於存放 Memory 之中，避 免過多的存取硬碟造成負擔。最後由 Log Monitor 從 Memory 取得 KBL，此 時才存放到硬碟成實體檔案。另一方面，Monitor Device 利用封包擷取工具 (Network Sniffer)擷取 PBL，可以判斷是否有遺失網路封包，以及分析網路 通訊裝置的外顯網路協定行為。之後利用 Log Matcher 將 KBL 與 PBL 作對 應，讓使用者清楚地觀察封包經過核心系統所留下的處理過程。最後使用 Integrated Viewer 從 KBL 與 PBL 之中，標示出特定網路封包進出核心系統 與其在外的網路協定行為，協助開發者排除問題或者找出網路通訊協定堆疊 的效能瓶頸。然而，Integrated Viewer 的診斷功能不包含於本論文的討論之 中，我們將之列為未來工作的項目。以下將分別介紹選擇性指令嵌入技術與 封包關聯技術。

4.3 選擇性指令嵌入技術之設計

本技術首先選擇觀察 Linux，主要原因是因為 Linux 作業系統本身的網路功 能已經相當成熟，也支援大多數的網路通訊協定，而且 Linux 的原始程式碼是開 放且容易取得，因此我們可以很容易地觀察到核心系統內部的原始程式碼。 觀察 Linux 核心系統的原始程式碼之後，發現網路封包處理函式皆擁有一個 共同點，這些函式都至少傳遞或回傳一個結構型態為 struct sk_buff 的參數，以及 宣告全域變數與區域變數的型態為 struct sk_buff，如 Figure 4-2。

A

B

struct sk_buff skb; FuncA(…) { 　Access skb; }

C

FuncB(…) { 　struct sk_buff skb; 　Access skb; }

D

Figure 4-2 網路封包處理函式(A：全域變數，B：傳遞參數，C：回傳參數，D：區域變 數) 而 struct sk_buff 為核心系統內部用於管理與儲存網路封包的資料結構[45]， 因此得知網路封包處理函式是利用函式呼叫中傳遞與回傳 struct sk_buff 參數的 特性來維護與交換網路封包的內容與相關資訊，所以我們可以利用 struct sk_buff 作為關鍵字尋找出所有的網路封包處理函式。 大部分的這類函式會直接宣告 struct sk_buff 作為參數或者變數，我們稱此特 性為資料型態的直接引用(Direct use)。如 Figure 4-2 即是 Direct use。然而單純使 用 struct sk_buff 作為尋找的關鍵字，會遭遇到以下兩種情況：

 Polymorphism of sk_buff

由於程式語言的關係，程式開發者可以讓一種資料型態存在於多種變化 形式之中，所以單純使用 struct sk_buff 作為尋找的字句，並未能有效且完整 地尋找網路封包處理函式。

 Indirect use of sk_buff

有些例外的網路封包處理函式並未直接使用 struct sk_buff 或其變形作 為參數資料型態或者回傳資料型態，但是卻透過呼叫 Direct use function 或 者被 Direct use function 呼叫的關係，間接地實質存取 struct sk_buff。

由於 Linux 核心系統主要是 C 語言開發而成，因此以下將以 C 語言為範例， 詳細介紹這兩種情況。

4.3.1 Polymorphism of sk_buff

Polymorphism of sk_buff 的情形是 struct sk_buff 存在於多種變形之中，因此 我們可以將其分類為以下三種：(1)別名(Alias)，(2)客製化資料型態(Customized Data Types)，(3)巢狀結構(Nested Structure)，如 Figure 4-3。

Alias

Customized Data Types

Nested Structure

#define SK_BUFF_ALIAS struct sk_buff

typedef struct sk_buff SK_BUFF_TYPE;

struct A { … struct sk_buff skb; … }; struct B { … struct A a; … };

Figure 4-3 Polymorphism of sk_buff  Alias

即是利用 Macro 產生一個新的識別名稱取代 struct sk_buff，Compiler 會 於原始程式碼進行編譯之前，執行 Preprocessor 將新的識別名稱替換還原成

struct sk_buff，最後才編譯原始程式碼。

 Customized Data Types

利用 typedef 將 struct sk_buff 重新定義其識別名稱，與 Alias 不同的地方 是 Customized Data Types 於 Compiler 編譯程式碼時才轉換新的識別名稱成

struct sk_buff，而不是於 Preprocessor 階段。

 Nested Structure

將 struct sk_buff 與其他資料型態組合成一個新的資料型態，因此新的資 料型態與 struct sk_buff 產生關聯，網路封包處理函式則可以透過新的資料型 態存取 struct sk_buff。

然而實際上有可能存在 Multi-level Polymorphism of sk_buff，如 Figure 4-4，

struct sk_buff 存在於 Alias，而 struct sk_buff 再經由 Alias 存在於 Nested Structure，

因此我們將考慮 Multi-level Polymorphism of sk_buff 的情況。

Alias of sk_buff

Nested Structure {

…

Alias of sk_buff

…

};

Figure 4-4 Multi-level Polymorphism of sk_buff

所以我們必頇於尋找封包處理函式之前，尋找程式原始碼內部 struct sk_buff 存在的多種變化形式，始能判斷函式是否至少傳遞或回傳一個結構型態為 struct

sk_buff 或其變形的參數，以準確找出封包處理函式。而本論文將此類的封包處

4.3.2 Direct / Indirect use of sk_buff

Indirect use of sk_buff 的情形是有些例外的網路封包處理函式利用 Direct use of sk_buff 的特性，透過呼叫 Direct use function 或者被 Direct use function 呼叫的 關係，間接地實質存取 struct sk_buff，因此我們可以再將其細分為以下兩種情況： (1)Indirect Caller，(2)Indirect Callee，如 Figure 4-5。

void FunB(

struct sk_buff

*skb, …);

void FunA(…)

{

void

*ptr;

FunB(skb, …);

…

}

FunA

Call

_{(Direct use function}

FunB

₎

void FunC(

void

*ptr, …);

void FunB(

struct sk_buff

*skb, …) {

…

FunC(skb, …);

…

}

FunB

(Direct use function)

Call

FunC

Indirect Caller

Indirect Callee

Figure 4-5 Indirect use of sk_buff  Indirect Caller

由於 Direct use of sk_buff，Direct use function 必頇從 Caller 取得 struct

sk_buff，始能處理網路封包，如 Figure 4-5 所表示，FunA 將 struct sk_buff

透過函式呼叫傳遞給 FunB，讓 FunB 得以存取 struct sk_buff，因此 FunA 藉 由呼叫 FunB 間接存取 struct sk_buff。另一方面，FunA 也可能透過呼叫 FunB，讓 FunB 回傳 struct sk_buff。

 Indirect Callee

Direct use function 可能透過函式呼叫將 struct sk_buff 傳遞給 Callee，如 Figure 4-5 所示，FunB 將 struct sk_buff 透過函式呼叫傳遞給 FunC，讓 FunC 得以存取 struct sk_buff。另一方面，FunB 也可能透過呼叫 FunC，讓 FunC 回傳 struct sk_buff。

所以我們必頇先尋找所有的 Direct use function 之後，再透過 Direct use function 搜尋核心系統內部所有函式之間的呼叫關係，以準確找出利用 Indirect use of sk_buff 的網路封包處理函式，因此我們將此類函式，歸類為 Indirect use function。

然而也可能存在 Multi-level Indirect use of sk_buff，由於 Indirect use of sk_buff 分成 Indirect Caller 與 Indirect Callee，我們首先說明 Multi-level of Indirect Caller， 如 Figure 4-6，FunD 為 Indirect use function，FunD 呼叫 FunB 傳遞 struct sk_buff， 但是 FunD 卻是因為被 FunE 呼叫，從 FunE 取得 struct sk_buff，因此 FunE 也成 為 Indirect use function。

FunE(…) {

void *skb;

FunD(

skb

);

…

}

FunE

Call

_{(Indirect use function}

FunD

₎

Call

_{(Direct use function}

FunB

₎

FunD(

void *ptr

) {

…

FunB(

ptr

);

…

}

Figure 4-6 Multi-level of Indirect Caller

而 Multi-level Indirect Callee，如 Figure 4-7，FunF 為 Indirect use function， 而 FunG 因為被 FunF 呼叫，從 FunF 取得 struct sk_buff，因此 FunG 也成為 Indirect use function。

FunB(

struct sk_buff *skb

) {

…

FunF(

skb

);

…

}

FunB

(Direct use function) (Indirect use function

FunF

)

Call

FunG

Call

FunF(

void *ptr

) {

…

FunG(

ptr

);

…

}

Figure 4-7 Multi-level of Indirect Callee

因此我們尋找 Indirect use function 時，也將考慮 Multi-level Indirect use of

sk_buff 的情況，判斷函式傳遞與回傳的參數值是否與 struct sk_buff 有實質關聯。

藉此找出所有的 Indirect use function。

結論是選擇性指令嵌入技術利用 Direcet use of sk_buff 的特性，並且解決 Polymorphism of sk_buff 與 Indirect use of sk_buff，自動嵌入指令於網路封包處理 函式內部，得以追蹤封包處理函式的執行順序，並且記錄封包相關資訊。

4.3.3 選擇性指令嵌入技術之架構

Polymorphism

Direct use

function

PT

DT

Indirect use

function

IT

1.

2.

3.

Selective

Instrumentation

Patched

Source Code

Original

Source Code

PT: Polymorphism Table

DT: Direct use Table

IT: Indirect use Table

Control Flow

Data Flow

Figure 4-8 選擇性指令嵌入技術之架構

Figure 4-8 為選擇性指令嵌入技術的架構，分成三個部分：(1)Polymorphism Module 負責調查原始程式碼，以及尋找 struct sk_buff 的所有變形，將結果儲存 於 Polymorphism Table。(2)Direct use function Module 從 Polymorphism Table 取得

struct sk_buff 的所有變形後，負責搜尋與嵌入指令於 Direct use function，將搜尋

結果儲存於 Direct use Table。(3)Indirect use function Module 從 Direct use Table 取 得所有 Direct use function 的資訊，負責搜尋與嵌入指令於 Indirect use function， 最後將搜尋結果儲存於 Indirect use Table。核心系統的原始程式碼經過這三個流 程之後，產生嵌入剖析與除錯指令的原始程式碼。以下將詳細介紹選擇性指令嵌 入之重要元件。

 Polymorphism Module

此元件主要目的為搜尋原始程式碼，尋找 struct sk_buff 的所有變形，將 搜尋結果儲存於 Polymorphism Table。我們利用虛擬程式碼(Pseudo Code)說 明 Polymorphism Module 尋找所有變形的程序，如 Figure 4-9。搜尋所有原 始程式碼，當尋找到 Polymorphism of sk_buff，再利用此變形繼續尋找，直 到尋找完所有原始程式碼。

Poly(struct sk_buff) 1　For each input file

2　　If find polymorphism of sk_buff

3　　　Then Poly(polymorphism of sk_buff)

 Direct use function Module

此元件主要目的為尋找與嵌入剖析與除錯指令於 Direct use function， Direct use function Module 從 Polymorphism Table 取得 struct sk_buff 的所有變 形之後，搜尋且嵌入指令於所有 Direct use function，最後將找到的 Direct use function 相關資訊儲存於 Direct use Table。DPPF 的相關資訊有：(1)Direct use function 的函式名稱，(2)資料型態為 struct sk_buff 或其變形的參數型態、名 稱與位置。

 Indirect use function Module

此元件主要目的為尋找與嵌入剖析與除錯指令於 Indirect use function， Indirect use function Module 藉由 Direct use Table 取得 Direct use function 的 資訊，尋找且嵌入指令於 Indirect use function，最後將結果儲存於 Indirect use Table。然而 Indirect use function 可以分為 Indirect Caller 與 Indirect Callee 兩 種，因此 Indirect use function Module 將分別尋找，我們利用虛擬碼(Pseudo Code)說明 Indirect use function Module 的 Caller 與 Callee 尋找 Indirect-Caller 與 Indirect-Callee 的過程。

如 Figure 4-10，Caller 找到 Direct use function 的 Caller，而 Direct use function 的 Caller 必定為 Indirect use function。因此觀察 Indirect use function 的參數或回傳值是否與 struct sk_buff 有實質關連，判斷是否繼續尋找 Indirect use function。

Caller(Direct use function) 1　For each function

2　　If find Caller of Direct use function

3　　　Then Indirect use function = Caller of Direct use function

4　　　 If param. Or return of Indirect use function have association with struct sk_buff 5 　Then Caller(Indirect use function)

Figure 4-10 Pseudo Code of Caller

如 Figure 4-11，Callee 尋找 Direct use function 的所有 function call，觀 察 callee 的引數(Argument)或回傳值是否與 struct sk_buff 有實質關連。如果 有關連，則該 callee 為 Indirect use function，以此 Indirect use function 繼續 尋找 Indirect Callee。

Callee(Direct use function)

1　For each function call of Direct use function

2　　If argu. Or return of callee have association with struct sk_buff

3　　　Then Indirect use function = callee

4　　　　 Callee(Indirect use function)