Linux 核心模組運作原理

--- tags: LINUX KERNEL, LKI --- # Linux 核心模組運作原理 > 資料整理: [jserv](http://wiki.csie.ncku.edu.tw/User/jserv) 本文從分析 [Hello World](https://en.wikipedia.org/wiki/%22Hello,_World!%22_program) 等級的 Linux 核心模組出發，探究 Linux 核心掛載和卸載核心模組背後的運作機制，理解這些概念後，再實作[可自我隱藏蹤跡的 Linux 核心模組](https://github.com/sysprog21/lkm-hidden) 作為驗證。 :::success 「幹壞事是進步最大的原動力」 -- [gslin](https://blog.gslin.org/) ::: ## 基本概念 [鳥哥私房菜: Linux 核心編譯與管理](http://linux.vbird.org/linux_basic/centos7/0540kernel.php) ### 從 Hello World 開始不免俗，從 Hello world 開始。 ![](https://i.imgur.com/qnSJ9CI.png) ### 前期準備自從 Linux 核心 4.4 版以來，Ubuntu Linux 預設開啟 `EFI_SECURE_BOOT_SIG_ENFORCE`，這使得核心模組需要適度的簽章才可掛載進入 Linux 核心，為了後續測試的便利，我們需要將 UEFI Secure Boot 的功能**關閉**，請見 [Why do I get “Required key not available” when install 3rd party kernel modules or after a kernel upgrade?](https://askubuntu.com/questions/762254/why-do-i-get-required-key-not-available-when-install-3rd-party-kernel-modules) * 檢查 Linux 核心版本 ```shell $ uname -r ``` 預期是大於等於 `5.4.0` 的版本，例如 `5.4.0-66-generic`。若在你的開發環境中，核心版本低於 `5.4` 的話，需要更新 Linux 核心，請自行參照相關文件 * 安裝 `linux-headers` 套件 (注意寫法裡頭有 `s`)，以 [Ubuntu Linux 20.04 LTS](https://packages.ubuntu.com/focal/linux-headers-generic) 為例: ```shell $ sudo apt install linux-headers-`uname -r` ``` * 確認 `linux-headers` 套件已正確安裝於開發環境 ```shell $ dpkg -L linux-headers-`uname -r` | grep "/lib/modules/.*/build" ``` 預期得到以下輸出: ``` /lib/modules/5.4.0-66-generic/build ``` * 檢驗目前的使用者身份 ```shell $ whoami ``` 預期為「不是 root 的使用者名稱」，例如 `jserv` (或者你安裝 Ubuntu Linux 指定的登入帳號名稱)。由於測試過程需要用到 sudo，請一併查驗: ```shell $ sudo whoami ``` 預期輸出是 `root` :notes: 在下列操作中，請==避免用 root 帳號輸入命令==，而該善用 `sudo` :::danger 之後的實驗中，若濫用 root 權限，可能會破壞 GNU/Linux 開發環境 (當然，你還是可重新安裝)，現在開始養成好習慣 ::: ### 程式碼準備建立 `hello` 目錄並在其中建立 `Makefile` 及 `hello.c` - [ ] `hello.c` ```cpp #include <linux/init.h> #include <linux/module.h> MODULE_LICENSE("Dual BSD/GPL"); static int hello_init(void) { printk(KERN_INFO "Hello, world\n"); return 0; } static void hello_exit(void) { printk(KERN_INFO "Goodbye, cruel world\n"); } module_init(hello_init); module_exit(hello_exit); ``` - [ ] `Makefile` ``` obj-m := hello.o clean: rm -rf *.o *.ko *.mod.* *.symvers *.order *.mod.cmd *.mod ``` > 注意 `clean:` 下一行 `rm -rf` 之前要用 tab 分隔，而非空白 ### 建構核心模組編譯核心模組的命令: ```shell $ make -C /lib/modules/`uname -r`/build M=`pwd` modules ``` 成功後會產出許多檔案，這邊我們會用到的只有 `hello.ko` 值得注意的是你可能在編譯過程結果會看到下面的敘述: ``` warning: the compiler differs from the one used to build the kernel The kernel was built by: gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0 You are using: gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 ``` 表示你的編譯器版本與kernel開發套件所用的編譯器版本不一致，建議安裝對應的版本避免後續開發出問題。 ### 掛載核心模組產生 `hello.ko` 之後，可將其掛載: ```shell $ sudo insmod hello.ko ``` `dmesg` 命令可顯示核心訊息 ``` [ 3824.676183] Hello, world ``` ### 卸載核心模組其卸載稍早載入的 `hello` 核心模組: ``` $ sudo rmmod hello ``` `dmesg` 顯示核心訊息 ``` [ 3824.676183] Hello, world [ 3921.232076] Goodbye, cruel world ``` 以上為第一個 Linux 核心模組的撰寫、掛載及卸載。繼續參閱以下教材: * ==[The Linux Kernel Module Programming Guide](https://github.com/sysprog21/lkmpg)== * [Introduction to Linux kernel driver programming](https://events.linuxfoundation.org/wp-content/uploads/2017/12/Introduction-to-Linux-Kernel-Driver-Programming-Michael-Opdenacker-Bootlin-.pdf) * [Part 1: Introduction](http://derekmolloy.ie/writing-a-linux-kernel-module-part-1-introduction/) * [Part 2: A Character Device](http://derekmolloy.ie/writing-a-linux-kernel-module-part-2-a-character-device/) --- ## `fibdrv`: 可輸出 Fibonacci 數列的 Linux 核心模組取得原始程式碼 ```shell $ git clone https://github.com/sysprog21/fibdrv $ cd fibdrv ``` 編譯並測試 ```shell $ make check ``` 預期會看到綠色的 ` Passed [-]` 字樣，隨後是 ``` f(93) fail input: 7540113804746346429 expected: 12200160415121876738 ``` 這符合預期，因為給定的 `fibdrv` 存在==缺陷==。 :::info 就因世界不完美，才有我們工程師存在的空間。 ::: 觀察產生的 `fibdrv.ko` 核心模組 ```shell $ modinfo fibdrv.ko ``` 預期可得以下輸出: ``` description: Fibonacci engine driver author: National Cheng Kung University, Taiwan license: Dual MIT/GPL name: fibdrv vermagic: 5.4.0-45-generic SMP mod_unload ``` 觀察 `fibdrv.ko` 核心模組在 Linux 核心掛載後的行為（要先透過 `insmod` 將模組載入核心後才會有下面的裝置檔案 `/dev/fibonacci`） ```shell $ ls -l /dev/fibonacci $ cat /sys/class/fibonacci/fibonacci/dev ``` 新建立的裝置檔案 `/dev/fibonacci`，注意到 `236` 這個數字，在你的電腦也許會有出入。試著對照 [fibdev.c](https://github.com/sysprog21/fibdrv/blob/master/fibdrv.c)，找尋彼此的關聯。 ```shell $ cat /sys/module/fibdrv/version ``` 預期輸出是 `0.1`，這和 [fibdev.c](https://github.com/sysprog21/fibdrv/blob/master/fibdrv.c) 透過 `MODULE_VERSION` 所指定的版本號碼相同。 ```shell $ lsmod | grep fibdrv $ cat /sys/module/fibdrv/refcnt ``` 這兩道命令的輸出都是 `0`，意味著目前的 [reference counting](https://en.wikipedia.org/wiki/Reference_counting)。延伸閱讀: * [Fibonacci Driver 作業說明](https://hackmd.io/@sysprog/linux2022-fibdrv) --- ## Linux 核心模組掛載機制 - [ ] 檔案 [fibdrv.c](https://github.com/sysprog21/fibdrv/blob/master/fibdrv.c) 裡頭的 `MODULE_LICENSE`, `MODULE_AUTHOR`, `MODULE_DESCRIPTION`, `MODULE_VERSION` 等巨集做了什麼事，可以讓核心知曉呢？ `insmod` 這命令背後，對應 Linux 核心內部有什麼操作呢？這些巨集本質上就是在編譯過後在 `.ko` 檔 (`ko` 即 kernel object 之意，對比使用者層級的 shared object [相當於 Microsoft Windows 的 DLL]，可對照 [你所不知道的 C 語言：動態連結器篇](https://hackmd.io/@sysprog/c-dynamic-linkage)) 中提供相對應的資訊，由於性質相同，這邊就先專注於 `MODULE_AUTHOR`。在範例程式中我們指定 module 的作者 ```cpp MODULE_AUTHOR("National Cheng Kung University, Taiwan"); ``` 以下摘自 **[include/linux/module.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/module.h#L205)**: ```cpp /* * Author(s), use "Name <email>" or just "Name", for multiple * authors use multiple MODULE_AUTHOR() statements/lines. */ #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author) ``` 上述註解說明 `_author` 的格式和若有多個 author 則應該呼叫多次 `MODULE_AUTHOR`。若將巨集展開應得 `MODULE_INFO(author, "National Cheng Kung University, Taiwan")` ```cpp /* Generic info of form tag = "info" */ #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info) ``` 繼續將上述展開得 `__MODULE_INFO(author, author, "National Cheng Kung University, Taiwan")` 以下摘自 **[include/linux/moduleparam.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/moduleparam.h)**: ```cpp #ifdef MODULE #define __MODULE_INFO(tag, name, info) \ static const char __UNIQUE_ID(name)[] \ __used __attribute__((section(".modinfo"), unused, aligned(1))) \ = __stringify(tag) "=" info #else /* !MODULE */ /* This struct is here for syntactic coherency, it is not used */ #define __MODULE_INFO(tag, name, info) \ struct __UNIQUE_ID(name) {} #endif ``` 上述巨集的定義根據 `MODULE` 是否有被定義，`MODULE` 是在此核心模組被編譯時期所定義，若此模組編譯時已內建於核心則不會被定義。繼續將上述巨集展開 ```cpp static const char __UNIQUE_ID(author)[] \ __used __attribute__((section(".modinfo"), unused, aligned(1))) \ = __stringify(author) "=" "National Cheng Kung University, Taiwan" ``` 以下摘自 **[include/linux/compiler-gcc.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/compiler-gcc.h#L208)**: ```cpp #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) ``` 繼續將 \__UNIQUE_ID 展開，`__COUNTER__` 這個巨集由 GCC 自動更新，每當遇到使用到 `__COUNTER__` 就會將其值加一。 ```cpp static const char __PASTE(__PASTE(__UNIQUE_ID_, author), __COUNTER__)[] \ __used __attribute__((section(".modinfo"), unused, aligned(1))) \ = __stringify(author) "=" "National Cheng Kung University, Taiwan" ``` 1. `__UNIQUE_ID` 會根據參數產生一個不重複的名字（參考[linux/compiler.h](https://elixir.bootlin.com/linux/v4.15/source/include/linux/compiler.h#L161)），其中使用到的技術是利用巨集中的 `##` 來將兩個引數合併成一個新的字串。 2. 透過 `__attribute__` 關鍵字告訴編譯器，這段訊息 1. 要被放在 `.modinfo` 段 2. 應該不會被程式使用到，所以不要產生警告訊息 3. 最小的對齊格式需要是 1 bit > 延伸閱讀: [Specifying Attributes of Variables](https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Variable-Attributes.html) 3. 在 [linux/stringfy.h](https://elixir.bootlin.com/linux/v4.15/source/include/linux/stringify.h) 裡頭，我們可以看到 `__stringify` 的目的是為了把引數轉換成字串形式。以 `MODULE_LICENSE("Dual MIT/GPL")` 為例，被展開後的 `__stringify(tag) "=" info` 會是 `"license = Dual MIT/GPL"` 字串。總結這部份，`MODULE_XXX` 系列的巨集在最後都會被轉變成 ```cpp static const char 獨一無二的變數[] = "操作 = 參數" ``` 再放到 `.modinfo` 區段中。這裡對應到 C99/C11 規格書中的 6.4.5 String Literals: > In translation phase 6, the multibyte character sequences specified by any sequence of adjacent character and wide string literal tokens are concatenated into a single multibytecharacter sequence. 大致的意思是把 string literal 並排，等同於一個合併起來的字串。以下摘自 **[include/linux/compiler_types.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/compiler_types.h#L53)**: ```cpp /* Indirect macros required for expanded argument pasting, eg. __LINE__. */ #define ___PASTE(a,b) a##b #define __PASTE(a,b) ___PASTE(a,b) ``` 繼續展開: ```cpp static const char __UNIQUE_ID_author0[] \ __used __attribute__((section(".modinfo"), unused, aligned(1))) \ = __stringify(author) "=" "National Cheng Kung University, Taiwan" ``` 摘自 **[include/linux/stringify.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/stringify.h#L10)**: ```cpp #define __stringify_1(x...) #x #define __stringify(x...) __stringify_1(x) ``` 注意到 `#` 和 `##` 這兩個都是 preprocessor 語法，請參照 [你所不知道的 C 語言：前置處理器應用篇](https://hackmd.io/@sysprog/c-preprocessor) 以得知詳細用法。做最後的展開能夠得到以下的結果 ```cpp static const char __UNIQUE_ID_author0[] \ __used __attribute__((section(".modinfo"), unused, aligned(1))) \ = "author=National Cheng Kung University, Taiwan" ``` 根據 GNU GCC 文件說明對於 Variable attribute 的解說，`section` 會特別將此 variable 放到指定的 ELF section 中，這邊為 `.modinfo`。關於 ELF 的資訊，請參照 [你所不知道的 C 語言：連結器和執行檔資訊](https://hackmd.io/@sysprog/c-linker-loader)。 ``` $ objdump -s fibdrv.ko ... Contents of section .modinfo: 0000 76657273 696f6e3d 302e3100 64657363 version=0.1.desc 0010 72697074 696f6e3d 4669626f 6e616363 ription=Fibonacc 0020 6920656e 67696e65 20647269 76657200 i engine driver. 0030 61757468 6f723d4e 6174696f 6e616c20 author=National 0040 4368656e 67204b75 6e672055 6e697665 Cheng Kung Unive 0050 72736974 792c2054 61697761 6e006c69 rsity, Taiwan.li 0060 63656e73 653d4475 616c204d 49542f47 cense=Dual MIT/G 0070 504c0000 00000000 73726376 65727369 PL......srcversi 0080 6f6e3d34 42373436 37453631 43414238 on=4B7467E61CAB8 0090 32354539 35364446 38330000 00000000 25E956DF83...... 00a0 64657065 6e64733d 00726574 706f6c69 depends=.retpoli 00b0 6e653d59 006e616d 653d6669 62647276 ne=Y.name=fibdrv 00c0 00766572 6d616769 633d342e 31382e30 .vermagic=4.18.0 00d0 2d31362d 67656e65 72696320 534d5020 -16-generic SMP 00e0 6d6f645f 756e6c6f 61642000 mod_unload . ... ``` 上述可以看到 author 的資訊被寫入到 `.modinfo` section 中。更進一步，用 vim 打開 `fibdrv.ko`，並且使用 16 進位模式閱讀，可以在 [readelf](https://sourceware.org/binutils/docs/binutils/readelf.html) 輸出的 `modinfo` 區段的 `offset` (560) 中找到下面內容： ```hex 00000530: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000540: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000550: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000560: 7665 7273 696f 6e3d 302e 3100 6465 7363 version=0.1.desc 00000570: 7269 7074 696f 6e3d 4669 626f 6e61 6363 ription=Fibonacc 00000580: 6920 656e 6769 6e65 2064 7269 7665 7200 i engine driver. 00000590: 6175 7468 6f72 3d4e 6174 696f 6e61 6c20 author=National 000005a0: 4368 656e 6720 4b75 6e67 2055 6e69 7665 Cheng Kung Unive 000005b0: 7273 6974 792c 2054 6169 7761 6e00 6c69 rsity, Taiwan.li 000005c0: 6365 6e73 653d 4475 616c 204d 4954 2f47 cense=Dual MIT/G 000005d0: 504c 0000 0000 0000 7372 6376 6572 7369 PL......srcversi 000005e0: 6f6e 3d32 3444 4335 4642 3745 3736 3038 on=24DC5FB7E7608 000005f0: 4146 3136 4230 4343 3146 0000 0000 0000 AF16B0CC1F...... 00000600: 6465 7065 6e64 733d 0072 6574 706f 6c69 depends=.retpoli 00000610: 6e65 3d59 006e 616d 653d 6669 6264 7276 ne=Y.name=fibdrv 00000620: 0076 6572 6d61 6769 633d 342e 3138 2e30 .vermagic=4.18.0 00000630: 2d31 352d 6765 6e65 7269 6320 534d 5020 -15-generic SMP 00000640: 6d6f 645f 756e 6c6f 6164 2000 0000 0000 mod_unload ..... 00000650: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000660: 0000 0000 0000 0000 0000 0000 0000 0000 ................ ``` 再來看執行 `insmod` 時 Linux 核心做了什麼。摘自 [Linux Device Driver 3/e](https://lwn.net/Kernel/LDD3/) 第 2 章的資訊： > ...The use of module_init is mandatory. This macro adds a special section to the module’s object code stating where the module’s initialization function is to be found. Without this definition, your initialization function is never called. 可知 `module_init` 巨集在編譯出來的 object 中，加入初始化模組函數的起始位置。類似地，`module_exit` 的相關敘述： > Once again, the module_exit declaration is necessary to enable to kernel to find your cleanup function. ![image](https://hackmd.io/_uploads/r127fL5lR.png) 這邊利用 [strace](https://linux.die.net/man/1/strace) 追蹤執行 `insmod fibdrv.ko` 的過程有哪些系統呼叫被執行: ```shell= $ sudo strace insmod fibdrv.ko execve("/sbin/insmod", ["insmod", "fibdrv.ko"], 0x7ffeab43f308 /* 25 vars */) = 0 brk(NULL) = 0x561084511000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=83948, ...}) = 0 mmap(NULL, 83948, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0621290000 close(3) = 0 ... close(3) = 0 getcwd("/tmp/fibdrv", 4096) = 24 stat("/tmp/fibdrv/fibdrv.ko", {st_mode=S_IFREG|0644, st_size=8288, ...}) = 0 openat(AT_FDCWD, "/tmp/fibdrv/fibdrv.ko", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=8288, ...}) = 0 mmap(NULL, 8288, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f06212a2000 finit_module(3, "", 0) = 0 munmap(0x7f06212a2000, 8288) = 0 close(3) = 0 exit_group(0) = ? +++ exited with 0 +++m ``` 自上述第 18 行可以發現呼叫到 [finit_module](https://linux.die.net/man/2/finit_module)。去查看 linux 核心中如何宣告和實作 `finit_module`。 **[kernel/module.c](https://elixir.bootlin.com/linux/v4.18/source/kernel/module.c)** ```clike= SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags) { // ... return load_module(&info, uargs, flags); } ``` 在第 4 行可以發現執行 `load_module` 這個函式: ```cpp /* Allocate and load the module: note that size of section 0 is always zero, and we rely on this for optional sections. */ static int load_module(struct load_info *info, const char __user *uargs, int flags) { ... } ``` 在 Linux kernel v6.8.5 中， `finit_module` 系統呼叫的實作方式已變更，呼叫 `idempotent_init_module` 後在該函式當中還會呼叫 `init_module_from_file` ，在 `init_module_from_file` 才真正呼叫到 `load_module`。舊版核心原始程式碼的 [kernel/module.c](https://elixir.bootlin.com/linux/v4.18/source/kernel/module.c) 已在新版拆解成若干檔案，前述程式碼如今在 [kernel/module/main.c](https://elixir.bootlin.com/linux/latest/source/kernel/module/main.c)。而在註解的部分可以看到 `load_module` 大致就是 Linux 核心為模組配置記憶體和載入模組相關資料的地方。 - [ ] 當我們透過 `insmod` 去載入一個核心模組時，為何 `module_init` 所設定的函式得以執行呢？Linux 核心做了什麼事呢? 首先，先看看原始碼 ```cpp static int __init init_fib_dev(void) { // ... } static void __exit exit_fib_dev(void) { // ... } module_init(init_fib_dev); module_exit(exit_fib_dev); ``` 以下摘自 **[include/linux/module.h](https://elixir.bootlin.com/linux/v4.18/source/include/linux/module.h#L129)**: ```cpp= /* Each module must use one module_init(). */ #define module_init(initfn) \ static inline initcall_t __maybe_unused __inittest(void) \ { return initfn; } \ int init_module(void) __attribute__((alias(#initfn))); ``` 在第 5 行，可以看到 gcc 會在編譯過後將 `initfn` 設為 `int init_module(void)` 的別名。 :::info 1. 請參閱 ==[GCC 手冊](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)==，得知 `__attribute__((alias( ..)))` 的用法。 2. 可透過 `gcc -E fibdrv.c -I$TREE/include -I$TREE/arch/x86/include -I$TREE/include/uapi` 看到經過前置處理後的程式碼，`$TREE` 指的是核心原始程式碼的路徑，即 `/usr/src/linux-headers-$(uname -r)` 參考 [Stack Overflow - Kernel module source file after preprocessing](https://stackoverflow.com/questions/21177935/kernel-module-source-file-after-preprocessing) ::: 在核心 v.6.5.0 ，輸入上述第二點的 gcc 命令會導致編譯錯誤 (找不到 [asm/rwonce.h](https://stackoverflow.com/questions/77661674/fatal-error-asm-rwonce-h-no-such-file-or-directory-symlink-not-enough))，改成上述命令可以產出一段結果 (但與教材的預期結果不一樣) ```bash gcc -E fibdrv.c -I$TREE/include -I$TREE/arch/x86/include -I$TREE/arch/x86/include/generated ``` 在 `linux/module.h` 裏面，有兩處定義 `module_init`，分別是還沒定義 `MODULE` 的 ```cpp #ifndef MODULE #define module_init(x) __initcall(x); ``` 還有已定義 `MODULE` 的 ```cpp #else /* MODULE */ ... /* Each module must use one module_init(). */ #define module_init(initfn) \ static inline initcall_t __maybe_unused __inittest(void) \ { return initfn; } \ int init_module(void) __copy(initfn) __attribute__((alias(#initfn))); ``` 從前置處理過後的結果可知，這裡選用沒定義 `MODULE` 的 `module_init(x)` ，也就是之後會繼續展開 `__initcall(x)`。 `__initcall(x)` 巨集被定義在 [linux/init.h](https://elixir.bootlin.com/linux/v4.15/source/include/linux/init.h) ```clike #define __initcall(fn) device_initcall(fn) ``` `device_initcall` 展開成 [`__define_initcall(fn, 6)`](https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-3.html#:~:text=__define_initcall(fn%2C%206))，最後會變成我們預處理看到的結果。最後展開的巨集 ```cpp static inline __attribute__((unused)) __attribute__((no_instrument_function)) initcall_t __attribute__((unused)) __inittest(void) { return init_fib_dev; } int init_module(void) __attribute__((alias("init_fib_dev")));; ``` 再來解讀: 首先是第一段 `static inline ....`，這邊用了一個小技巧讓我們可在編譯時期就知道傳入的 function pointer 是不是合法的。我們回傳的 `return init_fib_dev`，他的資料型態必須要和 `initcall_t` 相同，否則編譯器會報錯。 > 這種作法和 [BUG_ON](https://kernelnewbies.org/FAQ/BUG) 和 C++ 的 [static assertion](https://en.cppreference.com/w/cpp/language/static_assert) 相似。再來是 [init_module](http://man7.org/linux/man-pages/man2/init_module.2.html)，我們知道這個**系統呼叫**讓我們把一個 ELF image 載入到 kernel space，而在最後一行 `int init_module(void) __attribute__((alias("init_fib_dev")))` 的目的是為了替 `init_module` 取一個別名。之所以要這樣做，是因前面的地方有寫到 ```cpp /* These are either module local, or the kernel's dummy ones. */ extern int init_module(void); ``` 這行告訴我們說，有 `init_module` 可以使用，但是不在這個地方實作。那實作在什麼地方呢？就是我們寫的 `init_fib_dev`，因為我們把 `init_module` 取了一個別名叫作 `init_fib_dev`。總結一下，`module_init` 巨集幫我們做 2 件事 1. 檢查傳入的函式，回傳值是否正確 2. 把 `init_module` 和傳入的函式關聯起來，因為 `insmod` 指令實作內部會呼叫 `init_module`。如此一來呼叫 `init_module` 就等同於呼叫我們自己寫的函式。透過以下實驗可確認否達到別名的效果: ```cpp #include <stdio.h> int __func() { printf("In __func()\n"); return 0; } int func() __attribute__((alias("__func"))); /* no function body */ int main() { func(); return 0; } ``` 編譯並執行: ```shell $ gcc -o test test.c $ ./test In __func() ``` 因此執行 `init_module()` 就相當於執行使用者自定義的函式 `initfn`。再來繼續回到為什麼 init_module 會被執行？就要回想系統會呼叫 `finit_module` 再來 `load_module`。摘自 **[kernel/module.c](https://elixir.bootlin.com/linux/v4.18/source/kernel/module.c#L3785)**: ```cpp= /* Allocate and load the module: note that size of section 0 is always zero, and we rely on this for optional sections. */ static int load_module(struct load_info *info, const char __user *uargs, int flags) { struct module *mod; //... /* Figure out module layout, and allocate all the memory. */ mod = layout_and_allocate(info, flags); if (IS_ERR(mod)) { err = PTR_ERR(mod); goto free_copy; } // ... return do_init_module(mod); // ... } ``` 自第 11 行可發現，在 `do_init_module` 之前，核心先做 `layout_and_allocate` 為載入的 module 進行記憶體配置。最後在第 19 行對 module 做初始化。摘自 **[kernel/module.c](https://elixir.bootlin.com/linux/v4.18/source/kernel/module.c#L3456)**: ```cpp /* * This is where the real work happens. * * Keep it uninlined to provide a reliable breakpoint target, e.g. for the gdb * helper command 'lx-symbols'. */ static noinline int do_init_module(struct module *mod) { // ... /* Start the module */ if (mod->init != NULL) ret = do_one_initcall(mod->init); // ... } ``` 摘自 **[init/main.c](https://elixir.bootlin.com/linux/v4.18/source/init/main.c#L874)**: ```cpp= int __init_or_module do_one_initcall(initcall_t fn) { // ... do_trace_initcall_start(fn); ret = fn(); do_trace_initcall_finish(fn, ret); // ... } ``` 可見到 `fn` 亦即傳入的 `mod->init`，核心模組的 init_function 在上述程式碼第 6 行被執行，為核心模組進行真正的初始化的工作。 - [ ] 試著執行 `$ readelf -a fibdrv.ko`, 觀察裡頭的資訊和原始程式碼及 `modinfo` 的關聯，搭配上述提問，解釋像 `fibdrv.ko` 這樣的 ELF 執行檔案是如何「植入」到 Linux 核心 Executable and Linking Format 簡稱為 ELF，可以表示一個 executable binary file 或是 object file。由於這次實驗，`fibdrv.ko` 並非可執行檔，因此這邊專注於解釋 ELF 檔案以 object file 的觀點。ELF 可大致分為 3 個部分： 1. **ELF header** 存放了有關於此 object file 的訊息 ```shell $ readelf -h fibdrv.ko ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 6688 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 25 Section header string table index: 24 ``` 2. **Section(s)** 有系統預定義的 section，如 `.text`, `.data`, `.bss` 等等，但也有使用者定義的 section，在本例中就有 `.modinfo`. 3. **Section Header(s)** 有對應的關於每個 section 的 metadata。例如某 Section 的 size。 ```shell $ readelf -S fibdrv.ko There are 25 section headers, starting at offset 0x1a20: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 0000000000000000 00000040 0000000000000024 0000000000000000 A 0 0 4 [ 2] .text PROGBITS 0000000000000000 00000070 000000000000015c 0000000000000000 AX 0 0 16 [ 3] .rela.text RELA 0000000000000000 00001218 0000000000000120 0000000000000018 I 22 2 8 [ 4] .init.text PROGBITS 0000000000000000 000001cc 0000000000000153 0000000000000000 AX 0 0 1 [ 5] .rela.init.text RELA 0000000000000000 00001338 00000000000003a8 0000000000000018 I 22 4 8 [ 6] .exit.text PROGBITS 0000000000000000 0000031f 0000000000000040 0000000000000000 AX 0 0 1 [ 7] .rela.exit.text RELA 0000000000000000 000016e0 00000000000000d8 0000000000000018 I 22 6 8 [ 8] __mcount_loc PROGBITS 0000000000000000 0000035f 0000000000000030 0000000000000000 A 0 0 1 [ 9] .rela__mcount_loc RELA 0000000000000000 000017b8 0000000000000090 0000000000000018 I 22 8 8 [10] .rodata.str1.1 PROGBITS 0000000000000000 0000038f :q 000000000000006e 0000000000000001 AMS 0 0 1 [11] .rodata.str1.8 PROGBITS 0000000000000000 00000400 0000000000000058 0000000000000001 AMS 0 0 8 [12] .rodata PROGBITS 0000000000000000 00000460 0000000000000100 0000000000000000 A 0 0 32 [13] .rela.rodata RELA 0000000000000000 00001848 0000000000000090 0000000000000018 I 22 12 8 [14] .modinfo PROGBITS 0000000000000000 00000560 00000000000000ec 0000000000000000 A 0 0 8 [15] .data PROGBITS 0000000000000000 00000660 0000000000000020 0000000000000000 WA 0 0 32 [16] .rela.data RELA 0000000000000000 000018d8 ... ``` 再來看 `modinfo` 這個程式和 `fibdrv.ko` 的關聯。由稍早推斷，`MODULE_XXX` 等巨集會將 module 的額外資訊放入 `fibdrv.ko` 中 `.modinfo` 中，`modinfo` 這個程式應該就是到 `fibdrv.ko` 中的 `.modinfo` 區段讀取資料並做顯示。以下是 `man modinfo` 中關於 `modinfo` 的描述。 > DESCRIPTION > ==modinfo extracts information from the Linux Kernel modules== given on the command line. If the module name is not a filename, then the /lib/modules/version directory is > searched, as is also done by modprobe(8) when loading kernel modules. > ==modinfo by default lists each attribute of the module in form fieldname : value, for > easy reading.== The filename is listed the same way (although it's not really an > attribute). - [ ] 解釋像 `fibdrv.ko` 這樣的 ELF 執行檔案是如何「植入」到 Linux 核心 `fibdrv.ko` 不是能在 shell 呼叫並執行的執行檔，它只是 ELF 格式的 object file。如果 `fibdrv.ko` 是執行檔，那麼其內容應該會包含了 Program headers 這些訊息，但是查看 ELF header 可以發現並沒有 Program header。 ```shell $ readelf -h fibdrv.ko ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 6688 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 25 Section header string table index: 24 ``` 因此我們需要透過 `insmod` 這個程式（可執行檔）來將 `fibdrv.ko` 植入核心中。kernel module 是執行在 kernel space 中，但是 `insmod fibdrv.ko` 是一個在 user space 的程序，因此在 `insmod` 中應該需要呼叫相關管理記憶體的 system call，將在 user space 中 kernel module 的資料複製到 kernel space 中。回頭看之前說 `insmod` 會使核心執行 `finit_module` 摘自 **[linux/kernel/module.c](https://elixir.bootlin.com/linux/v4.18/source/kernel/module.c)**: ```cpp= SYSCALL_DEFINE3(finit_module, int, fd, const char __user *, uargs, int, flags) { struct load_info info = { }; loff_t size; void *hdr; int err; // ... err = kernel_read_file_from_fd(fd, &hdr, &size, INT_MAX, READING_MODULE); if (err) return err; info.hdr = hdr; info.len = size; return load_module(&info, uargs, flags); } ``` 在第 10 行核心會讀取一個檔案，在本例中，就是 `fibdrv.ko`: ```shell= $ sudo insmod fibdrv.ko ... getcwd("/tmp/fibdrv", 4096) = 24 stat("/tmp/fibdrv/fibdrv.ko", {st_mode=S_IFREG|0644, st_size=8288, ...}) = 0 openat(AT_FDCWD, "/tmp/fibdrv/fibdrv.ko", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=8288, ...}) = 0 mmap(NULL, 8288, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f06212a2000 finit_module(3, "", 0) = 0 ... ``` 可見上述執行 `strace insmod fibdrv.ko` 後，在第 5 行開啟 `fibdrv.ko` 這個檔案並得到其 file descriptor 為 `3`。並在第 8 行傳入 `finit_module` 中。 - [ ] sysfs 的原理和實作 Patrick Mochel 撰寫的報告 [The sysfs Filesystem](https://mirrors.edge.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf) 第 1 頁提到: > sysfs is a mechanism for representing kernel objects, their attributes, and their relationships with each other. 並在第 5 頁的 module 中提到： > The module directory contains subdirectories for each module that is loaded into the kernel.The name of each directory is the name of the module -- both the name of the module object file and the internal name of the module. `/sys/module` 這個目錄下會有以已載入 module 名稱命名的子目錄；在 [sysfs(5) -man page](http://man7.org/linux/man-pages/man5/sysfs.5.html) 提到，在 `/sys/module/`"module-name" 目錄中會有一些相關檔案，這些檔案分別紀錄了此 module 的一些資料，例如，傳入的參數值；另外，在 [/kernel/module.c - 1703 行](https://elixir.bootlin.com/linux/latest/source/kernel/module.c#L1721) 中， `module_add_modinfo_attrs`() 中，第 19行有 sysfs 相關的函式 `sysfs_create_file`: ```cpp= static int module_add_modinfo_attrs(struct module *mod) { struct module_attribute *attr; struct module_attribute *temp_attr; int error = 0; int i; mod->modinfo_attrs = kzalloc((sizeof(struct module_attribute) * (ARRAY_SIZE(modinfo_attrs) + 1)), GFP_KERNEL); if (!mod->modinfo_attrs) return -ENOMEM; temp_attr = mod->modinfo_attrs; for (i = 0; (attr = modinfo_attrs[i]) && !error; i++) { if (!attr->test || attr->test(mod)) { memcpy(temp_attr, attr, sizeof(*temp_attr)); sysfs_attr_init(&temp_attr->attr); error = sysfs_create_file(&mod->mkobj.kobj, &temp_attr->attr); ++temp_attr; } } return error; } ``` `sysfs_create_file` 函式的第二個參數為 `&temp_attr->attr`，而 `temp_attr` 是個指向 struct module_attribute [struct module_attribute](https://elixir.bootlin.com/linux/latest/source/include/linux/module.h#L52) 的指標: ```cpp struct module_attribute { struct attribute attr; ssize_t (*show)(struct module_attribute *, struct module_kobject *, char *); ssize_t (*store)(struct module_attribute *, struct module_kobject *, const char *, size_t count); void (*setup)(struct module *, const char *); int (*test)(struct module *); void (*free)(struct module *); }; ``` 第 1 行宣告 `attr`，其型態為 [struct attribute](https://elixir.bootlin.com/linux/latest/source/include/linux/sysfs.h#L30) ( 定義於 /include/linux/sysfs.h ) : ```cpp struct attribute { const char *name; umode_t mode; #ifdef CONFIG_DEBUG_LOCK_ALLOC bool ignore_lockdep:1; struct lock_class_key *key; struct lock_class_key skey; #endif }; ``` 延伸閱讀: 《[The Linux Kernel Module Programming Guide](https://sysprog21.github.io/lkmpg/)》 ## 可自我隱藏的 Linux 核心模組所謂「可自我隱藏」的 Linux 核心模組就是指，一旦掛載後，難以利用工具 (如 `lsmod` 命令) 得知其蹤跡，許多 [rootkit](https://en.wikipedia.org/wiki/Rootkit) 會採取這個策略，以欺瞞 Linux 系統管理者，從而為所欲為。本文並非探討 [rootkit](https://en.wikipedia.org/wiki/Rootkit)，但解析為何一個 Linux 核心模組得以匿蹤，不啻是理解 Linux 核心的切入點 —— 我們要充分考慮到 Linux 核心的運作機制，才能有效隱藏 Linux 核心模組。 [lkm-hidden](https://github.com/sysprog21/lkm-hidden) 是個 Linux 核心模組，有限度地展現上述隱藏自己的存在。在 [main.c](https://github.com/sysprog21/lkm-hidden/blob/master/main.c) 使用巨集宣告: ```cpp MODULE_DESCRIPTION("Catch Me If You Can"); ``` 這則 [Catch Me If You Can](https://en.wikipedia.org/wiki/Catch_Me_If_You_Can) 訊息，暗示這個核心模組掛載後，難以找到其蹤跡。主要程式碼在 [main.c](https://github.com/sysprog21/lkm-hidden/blob/master/main.c) 的 `hide_myself` 函式: ```cpp static void __init hide_myself(void) { struct vmap_area *va, *vtmp; struct module_use *use, *tmp; struct list_head *_vmap_area_list = (struct list_head *) kallsyms_lookup_name("vmap_area_list"); struct rb_root *_vmap_area_root = (struct rb_root *) kallsyms_lookup_name("vmap_area_root"); /* hidden from /proc/vmallocinfo */ list_for_each_entry_safe (va, vtmp, _vmap_area_list, list) { if ((unsigned long) THIS_MODULE > va->va_start && (unsigned long) THIS_MODULE < va->va_end) { list_del(&va->list); /* remove from red-black tree */ rb_erase(&va->rb_node, _vmap_area_root); } } /* hidden from /proc/modules */ list_del_init(&THIS_MODULE->list); /* hidden from /sys/modules */ kobject_del(&THIS_MODULE->mkobj.kobj); /* decouple the dependency */ list_for_each_entry_safe (use, tmp, &THIS_MODULE->target_list, target_list) { list_del(&use->source_list); list_del(&use->target_list); sysfs_remove_link(use->target->holders_dir, THIS_MODULE->name); kfree(use); } } ``` 前述提及 `THIS_MODULE` 巨集的作用，我們利用鏈結串列的行為，予以「脫鉤」，這樣才不會在 `/proc/module` 被發現。此外，當我們執行以下命令: ```shell sudo cat /proc/vmallocinfo | less ``` 清楚可見 Linux 核心個別函式對應的記憶體地址範圍，這樣會洩漏 Linux 核心模組的執行，於是也該迴避。這裡利用取得 `vmap_area_list` 和 `vmap_area_root` 符號，並變更內容。延伸閱讀: * [Hiding with a Linux Rootkit](https://0x00sec.org/t/hiding-with-a-linux-rootkit/4532) * [Hiding Kernel Modules from Userspace](https://xcellerator.github.io/posts/linux_rootkits_05/) * [rootkit-kernel-module](https://github.com/croemheld/lkm-rootkit)

Read more

2024q1 第 10 週測驗題

Linux 核心設計: 透過 eBPF 觀察作業系統行為

你所不知道的 C 語言: 浮點數運算

並行程式設計: 排程器