本文作者：

康華：計算機碩士，主要從事Linux作業系統核心、Linux技術標準、電腦保安、軟體測試等領域的研究與開發工作，現就職於資訊產業部軟體與積體電路促進中心所屬的MII-HP Linux軟體實驗室。如果需要可以聯絡通過[email protected]聯絡他。

摘要：在進行裝置驅動程式，核心功能模組等系統級開發時，通常需要在核心和使用者程式之間交換資訊。Linux提供了多種方法可以用來完成這些任務。本文總結了各種常用的資訊交換方法，並用簡單的例子演示這些方法各自的特點及用法。其中有大家非常熟悉的方法，也有特殊條件下方可使用的手段。通過對比明確這些方法，可以加深我們對Linux核心的認識，更重要的是，可以讓我們更熟練駕御linux核心級的應用開發技術。

核心空間(kernel-space) VS 使用者空間(user-space)

作為一個Linux開發者，首先應該清楚核心空間和使用者空間的區別。關於這個話題，已經有很多相關資料，我們在這裡簡單描述如下：

現代的計算機體系結構中儲存管理通常都包含保護機制。提供保護的目的，是要避免系統中的一個任務訪問屬於另外的或屬於作業系統的儲存區域。如在IntelX86體系中，就提供了特權級這種保護機制，通過特權級別的區別來限制對儲存區域的訪問。 基於這種構架，Linux作業系統對自身進行了劃分：一部分核心軟體獨立於普通應用程式，執行在較高的特權級別上，（Linux使用Intel體系的特權級3來執行核心。）它們駐留在被保護的記憶體空間上，擁有訪問硬體裝置的所有許可權，Linux將此稱為核心空間。

相對的，其它部分被作為應用程式在使用者空間執行。它們只能看到允許它們使用的部分系統資源，並且不能使用某些特定的系統功能，不能直接訪問硬體，不能直接訪問核心空間，當然還有其他一些具體的使用限制。（Linux使用Intel體系的特權級0來執行使用者程式。）

從安全形度講將使用者空間和核心空間置於這種非對稱訪問機制下是很有效的，它能抵禦惡意使用者的窺探，也能防止質量低劣的使用者程式的侵害，從而使系統執行得更穩定可靠。但是，如果像這樣完全不允許使用者程式訪問和使用核心空間的資源，那麼我們的系統就無法提供任何有意義的功能了。為了方便使用者程式使用在核心空間才能完全控制的資源，而又不違反上述的特權規定，從硬體體系結構本身到作業系統，都定義了標準的訪問介面。關於X86系統的細節，請查閱參考資料1

一般的硬體體系機構都提供一種“門”機制。“門”的含義是指在發生了特定事件的時候低特權的應用程式可以通過這些“門”進入高特權的核心空間。對於IntelX86體系來說，Linux作業系統正是利用了“系統門”這個硬體介面（通過呼叫int $0x80機器指令)，構造了形形色色的系統呼叫作為軟體介面，為應用程式從使用者態陷入到核心態提供了通道。通過“系統呼叫”使用“系統門”並不需要特別的許可權，但陷入到核心的具體位置卻不是隨意的，這個位置由“系統呼叫”來指定，有這樣的限制才能保證核心安全無虞。我們可以形象地描述這種機制：作為一個遊客，你可以買票要求進入野生動物園，但你必須老老實實的坐在觀光車上，按照規定的路線觀光遊覽。當然，不準下車，因為那樣太危險，不是讓你丟掉小命，就是讓你嚇壞了野生動物。

出於效率和程式碼大小的考慮，核心程式不能使用標準庫函式（當然還有其它的顧慮，詳細原因請查閱參考資料2）因此核心開發不如使用者程式開發那麼方便。而且由於目前（linux2.6還沒正式釋出）的核心是“非搶佔”的，因此正在核心空間執行的程序是不會被其他程序取代的（除非該程序主動放棄CPU的控制，比如呼叫sleep(),schedule()等），所以無論是在程序上下文中（比如正在執行read系統呼叫），還是在中斷上下文(正在中斷服務程式中)，核心程式都不能長時間佔用CPU，否則其它程式將無法執行，只能等待。

核心空間和使用者空間的相互作用

現在，越來越多的應用程式需要編寫核心級和使用者級的程式來一起完成具體的任務，通常採用以下模式：首先，編寫核心服務程式利用核心空間提供的許可權和服務來接收、處理和快取資料；然後編寫使用者程式來和先前完成的核心服務程式互動，具體來說，可以利用使用者程式來配置核心服務程式的引數，提取核心服務程式提供的資料，當然，也可以向核心服務程式輸入待處理資料。

比較典型的應用包括: Netfilter(核心服務程式：防火牆)VS Iptable（使用者級程式：規則設定程式）；IPSEC(核心服務程式：VPN協議部分)VS IKE(使用者級程式：vpn金鑰協商處理)；當然還包括大量的裝置驅動程式及相應的應用軟體。這些應用都是由核心級和使用者級程式通過相互交換資訊來一起完成特定任務的。

資訊互動方法

使用者程式和核心的資訊交換是雙向的，也就是說既可以主動從使用者空間向核心空間傳送資訊，也可以從核心空間向用戶空間提交資料。當然，使用者程式也可以主動地從核心提取資料。下面我們就針對核心和使用者互動資料的方法做一總結、歸納。

資訊互動按資訊傳輸發起方可以分為使用者向核心傳送/提取資料和核心向用戶空間提交請求兩大類，先來說說：
由使用者級程式主動發起的資訊互動。

使用者級程式主動發起的資訊互動

A編寫自己的系統呼叫

從前文可以看出，系統呼叫是使用者級程式訪問核心最基本的方法。目前linux大致提供了二百多個標準的系統呼叫（參見核心程式碼樹中的include/ asm-i386/unistd.h和arch/i386/kernel/entry.S檔案），並且允許我們新增自己的系統呼叫來實現和核心的資訊交換。比如我們希望建立一個系統呼叫日誌系統，將所有的系統呼叫動作記錄下來，以便進行入侵檢測。此時，我們可以編寫一個核心服務程式。該程式負責收集所有的系統呼叫請求，並將這些呼叫資訊記錄到在核心中自建的緩衝裡。我們無法在核心裡實現複雜的入侵檢測程式，因此必須將該緩衝裡的記錄提取到使用者空間。最直截了當的方法是自己編寫一個新系統呼叫實現這種提取緩衝資料的功能。當核心服務程式和新系統呼叫都實現後，我們就可以在使用者空間裡編寫使用者程式進行入侵檢測任務了，入侵檢測程式可以定時、輪訓或在需要的時候呼叫新系統呼叫從核心提取資料，然後進行入侵檢測了。

B編寫驅動程式

Linux/UNIX的一個特點就是把所有的東西都看作是檔案(every thing is a file)。系統定義了簡潔完善的驅動程式介面，客戶程式可以用統一的方法透過這個介面和核心驅動程式互動。而大部分系統的使用者和開發者已經非常熟悉這種介面以及相應的開發流程了。

驅動程式運行於核心空間，使用者空間的應用程式通過檔案系統中/dev/目錄下的一個檔案來和它互動。這就是我們熟悉的那個檔案操作流程：open() —— read() —— write() —— ioctl() —— close()。（需要注意的是也不是所有的核心驅動程式都是這個介面，網路驅動程式和各種協議棧的使用就不大一致，比如說套介面程式設計雖然也有open()close()等概念，但它的核心實現以及外部使用方式都和普通驅動程式有很大差異。）關於這部分的程式設計細節，請查閱參考資料3、4。

裝置驅動程式在核心中要做的中斷響應、裝置管理、資料處理等等各種工作這篇文章不去關心，我們把注意力集中在它與使用者級程式互動這一部分。作業系統為此定義了一種統一的互動介面，就是前面所說的open(), read(), write(), ioctl()和close()等等。每個驅動程式按照自己的需要做獨立實現，把自己提供的功能和服務隱藏在這個統一介面下。客戶級程式選擇需要的驅動程式或服務（其實就是選擇/dev/目錄下的檔案），按照上述介面和檔案操作流程，就可以跟核心中的驅動互動了。其實用面向物件的概念會更容易解釋，系統定義了一個抽象的介面（abstract interface），每個具體的驅動程式都是這個介面的實現（implementation）。

所以驅動程式也是使用者空間和核心資訊互動的重要方式之一。其實ioctl, read, write本質上講也是通過系統呼叫去完成的，只是這些呼叫已被核心進行了標準封裝，統一定義。因此使用者不必向填加新系統呼叫那樣必須修改核心程式碼，重新編譯新核心，使用虛擬裝置只需要通過模組方法將新的虛擬裝置安裝到核心中（insmod上）就能方便使用。關於此方面設計細節請查閱參考資料5，程式設計細節請查閱參考資料6。

在linux中，裝置大致可分為：字元裝置，塊裝置，和網路介面（字元裝置包括那些必須以順序方式，像位元組流一樣被訪問的裝置；如字元終端，串列埠等。塊裝置是指那些可以用隨機方式，以整塊資料為單位來訪問的裝置，如硬碟等；網路介面，就指通常網絡卡和協議棧等複雜的網路輸入輸出服務）。如果將我們的系統呼叫日誌系統用字元型驅動程式的方式實現，也是一件輕鬆愜意地工作。我們可以將核心中收集和記錄資訊的那一部分編寫成一個字元裝置驅動程式。雖然沒有實際對應的物理裝置，但這並沒什麼問題：Linux的裝置驅動程式本來就是一個軟體抽象，它可以結合硬體提供服務，也完全可以作為純軟體提供服務（當然，記憶體的使用我們是無法避免的）。在驅動程式中，我們可以用open來啟動服務，用read()返回處理好的記錄，用ioctl()設定記錄格式等，用close()停止服務，write()沒有用到，那麼我們可以不去實現它。然後在/dev/目錄下建立一個裝置檔案對應我們新加入核心的系統呼叫日誌系統驅動程式。

C: 使用proc 檔案系統

proc是Linux提供的一種特殊的檔案系統，推出它的目的就是提供一種便捷的使用者和核心間的互動方式。它以檔案系統作為使用介面，使應用程式可以以檔案操作的方式安全、方便的獲取系統當前執行的狀態和其它一些核心資料資訊。

proc檔案系統多用於監視、管理和除錯系統，我們使用的很多管理工具如ps,top等，都是利用proc來讀取核心資訊的。除了讀取核心資訊，proc檔案系統還提供了寫入功能。所以我們也就可以利用它來向核心輸入資訊。比如，通過修改proc檔案系統下的系統引數配置檔案（/proc/sys），我們可以直接在執行時動態更改核心引數；再如，通過下面這條指令：

echo 1 > /proc/sys/net/ip_v4/ip_forward

開啟核心中控制IP轉發的開關，我們就可以讓執行中的Linux系統啟用路由功能。類似的，還有許多核心選項可以直接通過proc檔案系統進行查詢和調整。

除了系統已經提供的檔案條目，proc還為我們留有介面，允許我們在核心中建立新的條目從而與使用者程式共享資訊資料。比如，我們可以為系統呼叫日誌程式（不管是作為驅動程式也好，還是作為單純的核心模組也好）在proc檔案系統中建立新的檔案條目，在此條目中顯示系統呼叫的使用次數，每個單獨系統呼叫的使用頻率等等。我們也可以增加另外的條目，用於設定日誌記錄規則，比如說不記錄open系統呼叫的使用情況等。關於proc檔案系統得使用細節，請查閱參考資料7。

D: 使用虛擬檔案系統

有些核心開發者認為利用ioctl（）系統呼叫往往會似的系統呼叫意義不明確，而且難控制。而將資訊放入到proc檔案系統中會使資訊組織混亂，因此也不贊成過多使用。他們建議實現一種孤立的虛擬檔案系統來代替ioctl()和/proc，因為檔案系統介面清楚，而且便於使用者空間訪問，同時利用虛擬檔案系統使得利用指令碼執行系統管理任務更家方便、有效。

我們舉例來說如何通過虛擬檔案系統修改核心資訊。我們可以實現一個名為sagafs的虛擬檔案系統，其中檔案log對應核心儲存的系統呼叫日誌。我們可以通過檔案訪問特普遍方法獲得日誌資訊：如

# cat /sagafs/log

使用虛擬檔案系統——VFS實現資訊互動使得系統管理更加方便、清晰。但有些程式設計者也許會說VFS 的API 介面複雜不容易掌握，不要擔心2.5核心開始就提供了一種叫做libfs的例程式幫助不熟悉檔案系統的使用者封裝了實現VFS的通用操作。有關利用VFS實現互動的方法看參考資料。

E: 使用記憶體映像

Linux通過記憶體映像機制來提供使用者程式對記憶體直接訪問的能力。記憶體映像的意思是把核心中特定部分的記憶體空間對映到使用者級程式的記憶體空間去。也就是說，使用者空間和核心空間共享一塊相同的記憶體。這樣做的直觀效果顯而易見：核心在這塊地址記憶體儲變更的任何資料，使用者可以立即發現和使用，根本無須資料拷貝。而在使用系統呼叫互動資訊時，在整個操作過程中必須有一步資料拷貝的工作——或者是把核心資料拷貝到使用者緩衝區，或只是把使用者資料拷貝到核心緩衝區——這對於許多資料傳輸量大、時間要求高的應用，這無疑是致命的一擊：許多應用根本就無法忍受資料拷貝所耗費的時間和資源。

我們曾經為一塊高速取樣裝置開發過驅動程式，該裝置要求在20兆取樣率下以1KHz的重複頻率進行16位實時取樣，每毫秒需要取樣、DMA和處理的資料量驚人，如果要使用資料拷貝的方法，根本無法達成要求。此時，記憶體映像成為唯一的選擇：我們在記憶體中保留了一塊空間，將其配置成環形佇列供取樣裝置DMA輸出資料。再把這塊記憶體空間對映到在使用者空間執行的資料處理程式上，於是，取樣裝置剛剛得到並傳送到主機上的資料，馬上就可以被使用者空間的程式處理。

實際上，記憶體影射方式通常也正是應用在那些核心和使用者空間需要快速大量互動資料的情況下，特別是那些對實時性要求較強的應用。X window系統的伺服器的虛擬記憶體區域，就可以被看做是記憶體映像用法的一個典型例子：X伺服器需要對視訊記憶體進行大量的資料交換，相對於lseek/write來說，將圖形顯示記憶體直接影射到使用者空間可以顯著提高效能。

並不是任何型別的應用都適合mmap，比如像串列埠和滑鼠這些基於流資料的字元裝置，mmap就沒有太大的用武之地。並且，這種共享記憶體的方式存在不好同步的問題。由於沒有專門的同步機制可以讓使用者程式和核心程式共享，所以在讀取和寫入資料時要有非常謹慎的設計以保證不會產生幹繞。

mmap完全是基於共享記憶體的觀念了，也正因為此，它能提供額外的便利，但也特別難以控制。

由核心主動發起的資訊互動

在核心發起的互動中，我們最關心和感興趣的應該是核心如何向用戶程式發訊息，使用者程式又是怎樣接收這些訊息的，具體問題通常集中在下面這幾個方面：核心可否呼叫使用者程式？是否可以通過向用戶程序發訊號來告知使用者程序事件發生？

前面介紹的互動方法最大的不同在於這些方式是由核心採取主動，而不是等系統呼叫來被動的返回資訊的。

A 從核心空間呼叫使用者程式。

即使在核心中，我們有時也需要執行一些在使用者級才提供的操作：如開啟某個檔案以讀取特定資料，執行某個使用者程式從而完成某個功能。因為許多資料和功能在使用者空間是現有的或者已經被實現了，那麼沒有必要耗費大量的資源去重複。此外，核心在設計時，為了擁有更好的彈性或者效能以支援未知但有可能發生的變化，本身就要求使用使用者空間的資源來配合完成任務。比如核心中動態載入模組的部分需要呼叫kmod。但在編譯kmod的時候不可能把所有的核心模組都訂下來（要是這樣的話動態載入模組就沒有存在意義了），所以它不可能知道在它以後才出現的那些模組的位置和載入方法。因此，模組的動態載入就採用瞭如下策略：載入任務實際上由位於使用者空間的modprobe程式幫助完成——最簡單的情形是modprobe用核心傳過來的模組名字作為引數呼叫insmod。用這種方法來載入所需要的模組。

核心中啟動使用者程式還是要通過execve這個系統呼叫原形，只是此時的呼叫發生在核心空間，而一般的系統呼叫則在使用者空間進行。如果系統呼叫帶引數，那將會碰到一個問題：因為在系統呼叫的具體實現程式碼中要檢查引數合法性，該檢查要求所有的引數必須位於使用者空間——地址處於0x0000000——0xC0000000之間，所以如果我們從核心傳遞引數（地址大於0xC0000000）,那麼檢查就會拒絕我們的呼叫請求。為了解決這個問題，我們可以利用set_fs巨集來修改檢查策略，使得允許引數地址為核心地址。這樣核心就可以直接使用該系統呼叫了。

例如：在kmod通過呼叫execve來執行modprobe的程式碼前需要有set_fs(KERNEL_DS):

......
set_fs(KERNEL_DS);

/* Go, go, go... */
if (execve(program_path, argv, envp) < 0)
return -errno;
上述程式碼中program_path 為"/sbin/modprobe"，argv為{ modprobe_path, "-s", "-k", "--", (char*)module_name, NULL }，envp為{ "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL }。

從核心中開啟檔案同樣使用帶引數的open系統呼叫，所需的仍是要先呼叫set_fs巨集。

B 利用brk系統呼叫來匯出核心資料

核心和使用者空間傳遞資料主要是用get_user(ptr)和put_user(datum,ptr)例程。所以在大部分需要傳遞資料的系統呼叫中都可以找到它們的身影。可是，如果我們不是通過使用者程式發起的系統呼叫——也就是說，沒有明確的提供使用者空間內的緩衝區位置——的情況下，如何向用戶空間傳遞核心資料呢？

顯然，我們不能再直接使用put_user()了，因為我們沒有辦法給它指定目的緩衝區。所以，我們要借用brk系統呼叫和當前程序空間：brk用於給程序設定堆空間的大小。每個程序擁有一個獨立的堆空間，malloc等動態記憶體分配函式其實就是程序的堆空間中獲取記憶體的。我們將利用brk在當前程序(current process)的堆空間上擴充套件一塊新的臨時緩衝區，再用put_user將核心資料匯出到這個確定的使用者空間去。

還記得剛才我們在核心中呼叫使用者程式的過程嗎？在那裡，我們有一個跳過引數檢查的操作，現在有了這種方法，可以另闢蹊徑了：我們在當前程序的堆上擴充套件一塊空間，把系統呼叫要用到的引數通過put_user()拷貝到新擴充套件得到的使用者空間裡，然後在呼叫execve的時候以這個新開闢空間地址作為引數，於是，引數檢查的障礙不復存在了。

char * program_path = "/bin/ls" ;

/* 找到當前堆頂的位置*/ 
mmm=current->mm->brk;
/* 用brk在堆頂上原擴展出一塊256位元組的新緩衝區*/
ret = brk(*(void)(mmm+256));
/* 把execve需要用到的引數拷貝到新緩衝區上去*/
put_user((void*)2,program_path,strlen(program_path)+1);
/* 成功執行/bin/ls程式！*/ 
execve((char*)(mmm+2));
/* 恢復現場*/
tmp = brk((void*)mmm);

這種方法沒有一般性（具體的說，這種方法有負面效應嗎），只能作為一種技巧，但我們不難發現：如果你熟悉核心結構，就可以做到很多意想不到的事情！

C: 使用訊號：

訊號在核心裡的用途主要集中在通知使用者程式出現重大錯誤，強行殺死當前程序，這時核心通過傳送SIGKILL訊號通知程序終止，核心傳送訊號使用send_sign(pid,sig)例程，可以看到訊號傳送必須要事先知道程序序號（pid），所以要想從核心中通過發訊號的方式非同步通知使用者程序執行某項任務，那麼必須事先知道使用者程序的程序號才可。而核心執行時搜尋到特定程序的程序號是個費事的工作，可能要遍歷整個程序控制塊連結串列。所以用訊號通知特定使用者程序的方法很糟糕，一般在核心不會使用。核心中使用訊號的情形只出現在通知當前程序（可以從current變數中方便獲得pid）做某些通用操作，如終止操作等。因此對核心開發者該方法用處不大。

類似情況還有訊息操作。這裡不羅嗦了。

總結  由使用者級程式主動發起的資訊互動，無論是採用標準的呼叫方式還是透過驅動程式介面，一般都要用到系統呼叫。而由核心主動發起資訊互動的情況不多。也沒有標準的介面，操作大不方便。所以一般情況下，儘可能用本文描述的前幾種方法進行資訊互動。畢竟，在設計的根源上，相對於客戶級程式，核心就被定義為一個被動的服務提供者。因此，我們自己的開發也應該儘量遵循這種設計原則。

參考資料

1 周明德，保護方式下的80386及其程式設計，清華大學出版社，1993

2 Robert Love, Linux Kernel Development，Sams Publishing，2003

3 W.Richard Stevens, Advanced Programming in the UNIX Environment，Addision Wesley,1992

4 W.Richard Stevens, UNIX Network Programming, Prentic Hall, 1998

5 Maurice J. Bach, The Design of the UNIX Operating System, Prentic Hall, 1990

6 Linux Device Driver, O’Reilly

7 Ori Pomerantz ,Linux Kernel Module Programming Guide, 1999

FROM: http://www.kerneltravel.net/jiaoliu/005.htm