跟蹤分析Linux核心5 0系統呼叫處理過程

2021-09-12 21:00:58 字數 2840 閱讀 6990

學號 358

舉例跟蹤分析linux核心5.0系統呼叫處理過程

cd linuxkernel

xz -d linux-

5.0.1

.tar.xz

tar -xvf linux-

5.0.tar.xz

cd linux-

5.0make i386_defconfig

make -j

編譯過程中可能會出現的問題

解決辦法:

製作根檔案系統

解決辦法

sudo apt-get install gcc-multilib
編譯

使用gdb跟蹤除錯核心

qemu -kernel /usr/src/linux-

5.0.1

/arch/x86/boot/bzimage -initrd .

./rootfs.img -s -

s

開啟另乙個終端視窗

gdb

(gdb) file vmlinux

(gdb) target remote:

1234

(gdb)

break start_kernel

過程**現問題時,缺少的元件按提示安裝5. 分析

分析:

首先,幾乎所有的核心模組均會在start_kernel進行初始化。在start_kernel中,會對各項硬體裝置進行初始化,包括一些page_address、tick等等,直到最後需要執行的rest_init中,會開始讓系統跑起來。那rest_init這個過程中,會呼叫kernel_thread()來建立核心執行緒kernel_init,它建立使用者的init程序,初始化核心,並設定成1號程序,這個程序會繼續做相關的系統初始化。然後,start_kernel會呼叫kernel_thread並建立kthreadd,負責管理核心中得所有執行緒,然後程序id會被設定為2。最後,會建立idle程序(0號程序),不能被排程,並利用迴圈來不斷調號空閒的cpu時間片,並且從不返回。

我的學號是358,選擇學號後兩位58系統呼叫( /usr/include/asm/unistd_32.h中檢視系統呼叫號)

ulimit:顯示(或設定)使用者可以使用的資源的限制(limit),這限制分為軟限制(當前限制)和硬限制(上限),其中硬限制是軟限制的上限值,應用程式在執行過程中使用的系統資源不超過相應的軟限制,任何的超越都導致程序的終止。

在test.c中增加函式,再重新編譯rootfs.img

一般情況下,使用者程序是不能訪問核心的。它既不能訪問核心所在的記憶體空間,也不能呼叫核心中的函式。系統呼叫是乙個例外。系統呼叫實際上就是乙個從使用者態到管態再恢復到使用者態的過程,使用者態可以說成間接操作記憶體的程式,而核心態也就是通過彙編**直接操作記憶體,而他們再轉換過程中,由於涉及上下文的切換問題,所以需要對內容進行保護,在進入中斷程式前,將核心態暫存器的值放入棧中,在程式結束後再進行出棧。其原理是:程序先用適當的值填充暫存器,然後呼叫乙個特殊的指令,這個指令會讓使用者程式跳轉到乙個事先定義好的核心中的乙個位置。程序可以跳轉到的固定的核心位置。這個過程檢查系統呼叫號,這個號碼告訴核心程序請求哪種服務。然後,它檢視系統呼叫表(sys_call_table)找到所呼叫的核心函式入口位址。接著,就呼叫函式,等返回後,做一些系統檢查,最後返回到程序。

舉例跟蹤分析Linux核心5 0系統呼叫處理過程

學號最後三位編號 008 使用ubuntu編譯linux核心5.0 編譯核心的過程中可能需要安裝的依賴庫 sudo apt get install libncurses5 dev libssl dev sudo apt get install build essential openssl sudo...

舉例跟蹤分析Linux核心5 0系統呼叫處理過程

學號274 一 編譯linux核心5.0.1 xz d linux 5.0.1.tar.xz tar xvf linux 5.0.1.tar 2.編譯 make i386 defconfig make j8 可能會出現缺少相關依賴的問題,使用 sudo apt get install 缺少的依賴 安...

跟蹤分析Linux核心5 0系統86號呼叫處理過程

致謝學號末位 186 跟蹤分析linux核心5.0系統呼叫處理過程 選擇系統呼叫號後兩位與學號後兩位相同的系統呼叫進行跟蹤分析 分析系統呼叫 保護現場與恢復現場 系統呼叫號及引數傳遞過程 配置核心編譯引數 編譯核心 製作根檔案系統 mkdir linuxkernel cd linuxkernel m...