linux核心空間與使用者空間資訊互動方法 communication between kernel space...

引自 http://blog.chinaunix.net/u1/41220/showart_484176.html

linux核心空間與使用者空間資訊互動方法 communication between kernel space and user space

筆記如下：

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

A編寫自己的系統調用

B編寫驅動程式

C: 使用proc 檔案系統

D: 使用虛拟檔案系統

E: 使用記憶體映像

由核心采取主動

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

B 利用brk系統調用來導出核心資料

C: 使用信号

--------------------------------------------------------------------------------------------------------------------

linux核心空間與使用者空間資訊互動方法

本文作者：

康華：計算機碩士，主要從事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);

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;

ret = brk(*(void)(mmm+256));

put_user((void*)2,program_path,strlen(program_path)+1);

execve((char*)(mmm+2));

tmp = brk((void*)mmm);

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

C: 使用信号：

信号在核心裡的用途主要集中在通知使用者程式出現重大錯誤，強行殺死目前程序，這時核心通過發送SIGKILL信号通知程序終止，核心發送信号使用send_sign(pid,sig)例程，可以看到信号發送必須要事先知道程序式号（pid），是以要想從核心中通過發信号的方式異步通知使用者程序執行某項任務，那麼必須事先知道使用者程序的程序号才可。而核心運作時搜尋到特定程序的程序号是個費事的工作，可能要周遊整個程序控制塊連結清單。是以用信号通知特定使用者程序的方法很糟糕，一般在核心不會使用。核心中使用信号的情形隻出現在通知目前程序（可以從current變量中友善獲得pid）做某些通用操作，如終止操作等。是以對核心開發者該方法用處不大。

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

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