您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關linux系統調用是如何實現的,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結了以下內容,希望大家根據這篇文章可以有所收獲。
這張圖畫了挺久的,主要是想讓大家可以從全局角度,看下linux內核中系統調用的實現。
在講具體的細節之前,我們先根據上圖,從整體上看一下系統調用的實現。
系統調用的實現基礎,其實就是兩條匯編指令,分別是syscall和sysret。
syscall使執行邏輯從用戶態切換到內核態,在進入到內核態之后,cpu會從 MSR_LSTAR 寄存器中,獲取處理系統調用內核代碼的起始地址,即上面的 entry_SYSCALL_64。
在執行 entry_SYSCALL_64 函數時,內核代碼會根據約定,先從rax寄存器中獲取想要執行的系統調用的編號,然后根據該編號從sys_call_table數組中找到對應的系統調用函數。
接著,從 rdi, rsi, rdx, r10, r8, r9 寄存器中獲取該系統調用函數所需的參數,然后調用該函數,把這些參數傳入其中。
在系統調用函數執行完畢之后,執行結果會被放到rax寄存器中。
最后,執行sysret匯編指令,從內核態切換回用戶態,用戶程序繼續執行。
如果用戶程序需要該系統調用的返回結果,則從rax中獲取。
總體流程就是這樣,相對來說,還是比較簡單的,主要就是先去理解syscall和sysret這兩條匯編指令,在理解這兩條匯編指令的基礎上,再去看內核源碼,就會容易很多。
有關syscall和sysret指令的詳細介紹,請參考Intel® 64 and IA-32 Architectures Software Developer’s Manual。
有了上面對系統調用的整理理解,我們接下來看下其具體的實現細節。
以write系統調用為例,其對應的內核源碼為:
在內核中,所有的系統調用函數都是通過 SYSCALL_DEFINE 等宏定義的,比如上面的write函數,使用的是 SYSCALL_DEFINE3。
將該宏展開后,我們可以得到如下的函數定義:
由上可見,SYSCALL_DEFINE3宏展開后為三個函數,其中只有__x64_sys_write是外部可訪問的,其它兩個都有被static修飾,不能被外部訪問,所以注冊到上文中提到的sys_call_table數組里的函數,應該就是這個函數。
那該函數是怎么注冊到這個數組的呢?
我們先不說答案,先來看下sys_call_table數組的定義:
由上可見,該數組各元素的默認值都是 __x64_sys_ni_syscall:
該函數也非常簡單,就是直接返回錯誤碼 -ENOSYS,表示系統調用非法。
sys_call_table數組定義的地方好像只設置了默認值,并沒有設置真正的系統調用函數。
我們再看看其他地方,看是否有代碼會注冊真正的系統調用函數到sys_call_table數組里。
可惜,并沒有。
這就奇怪了,那各系統調用函數到底是在哪里注冊的呢?
我們再回頭仔細看下sys_call_table數組的定義,它在設置完默認值之后,后面還include了一個名為asm/syscalls_64.h的頭文件,這個位置include頭文件還是比較奇怪的,我們看下它里面是什么內容。
但是,這個文件居然不存在。
那我們只能初步懷疑這個頭文件是編譯時生成的,帶著這個疑問,我們去搜索相關內容,確實發現了一些線索:
這個文件確實是編譯時生成的,上面的makefile中使用了syscalltbl.sh腳本和syscall_64.tbl模板文件來生成這個syscalls_64.h頭文件。
我們來看下syscall_64.tbl模板文件的內容:
這里確實定義了write系統調用,且標明了它的編號是1。
我們再來看下生成的syscalls_64.h頭文件:
這里面定義了很多好像宏調用一樣的東西。
__SYSCALL_COMMON,這個不就是sys_call_table數組定義那里define的那個宏嘛。
再去上面看下__SYSCALL_COMMON這個宏定義,它的作用是將sym表示的函數賦值到sys_call_table數組的nr下標處。
所以對于__SYSCALL_COMMON(1, sys_write)來說,它就是注冊__x64_sys_write函數到sys_call_table數組下標為1的槽位處。
而這個__x64_sys_write函數,正是我們上面猜測的,SYSCALL_DEFINE3定義的write系統調用,展開之后的一個外部可訪問的函數。
這樣就豁然開朗了,原來真正的系統調用函數的注冊,是通過先定義__SYSCALL_COMMON宏,再include那個根據syscall_64.tbl模板生成的syscalls_64.h頭文件來完成的,非常巧妙。
系統調用函數注冊到sys_call_table數組的過程,到這里已經非常清楚了。
下面我們繼續來看下哪里在使用這個數組:
do_syscall_64在使用,方式是先通過nr在sys_call_table數組中找到對應的系統調用函數,然后再調用該函數,將regs傳入其中。
這個流程和我們上面預估的一樣,且傳入的regs參數類型,和我們上面注冊的系統調用函數所需的類型也一樣。
那也就是說,regs參數的字段里,是帶著各系統調用函數所需的參數的,SYSCALL_DEFINE等宏展開出來的一系列函數,會從這些字段中提取出真正的參數,然后對其進行類型轉換,最后這些參數被傳入到最終的系統調用函數中。
對于上面的write系統調用宏展開后的那些函數,__x64_sys_write會先從regs中提取出di, si, dx字段作為真正參數,然后__se_sys_write會將這些參數轉成正確的類型,最后__do_sys_write函數被調用,轉換后的這些參數被傳入其中。
在系統調用函數執行完畢后,其結果會被賦值到了regs的ax字段里。
由上可見,系統調用函數的參數及返回值的傳遞,都是通過regs來完成的。
但文章開始的時候不是說,系統調用的參數及返回值的傳遞,是通過寄存器來完成的嗎,這里怎么是通過struct pt_regs的字段呢?
先別急,先來看下struct pt_regs的定義:
你有沒有發現,這里面的字段名都是寄存器的名字。
那是不是說,在執行系統調用的代碼里,有邏輯把各寄存器里的值放到了這個結構體的對應字段里,在結束系統調用時,這些字段里的值又被賦值到各個對應的寄存器里呢?
離真相越來越近。
我們繼續看使用了do_syscall_64的地方:
上圖中的entry_SYSCALL_64方法,就是系統調用流程中最重要的一個方法了,為了便于理解,我對該方法做了很多修改,并添加了很多注釋。
這里需要注意的是100行到121行這段邏輯,它將各寄存器的值壓入到棧中,以此來構建struct pt_regs對象。
這就能構建出一個struct pt_regs對象了?
是的。
我們回上面看下struct pt_regs的定義,看其字段名字及順序是不是和這里的壓棧順序正好相反。
我們再想下,當我們要構建一個struct pt_regs對象時,我們要為其在內存中分配一塊空間,然后用一個地址來指向這段空間,這個地址就是該struct pt_regs對象的指針,這里需要注意的是,這個指針里存放的地址,是這段內存空間的最小地址。
再看上面的壓棧過程,每一次壓棧操作我們都可以認為是在分配內存空間并賦值,當r15被最終壓入到棧中后,整個內存空間分配完畢,且數據也初始化完畢,此時,rsp指向的棧頂地址,就是這段內存空間的最小地址,因為壓棧過程中,棧頂的地址是一直在變小的。
綜上可知,在壓棧完畢后,rsp里的地址就是一個struct pt_regs對象的地址,即該對象的指針。
在構建完struct pt_regs對象后,123行將rax中存放的系統調用編號賦值到了rdx里,124行將rsp里存放的struct pt_regs對象的地址,即該對象的指針,賦值到了rsi中,接著后面執行了call指令,來調用do_syscall_64方法。
調用do_syscall_64方法之前,對rdi和rsi的賦值,是為了遵守c calling convention,因為在該calling convention中約定,在調用c方法時,第一個參數要放到rdi里,第二個參數要放到rsi里。
我們再去上面看下do_syscall_64方法的定義,參數類型及順序是不是和我們這里說的是完全一樣的。
在調用完do_syscall_64方法后,系統調用的整個流程基本上就快結束了,上圖中的129行到133行做的都是一些寄存器恢復的工作,比如從棧中彈出對應的值到rax,rip,rsp等等。
這里需要注意的是,棧中rax的值是在上面do_syscall_64方法里設置的,其存放的是系統調用的最終結果。
另外,在棧中彈出的rip和rsp的值,分別是用戶態程序的后續指令地址及其堆棧地址。
最后執行sysret,從內核態切換回用戶態,繼續執行syscall后面邏輯。
到這里,完整的系統調用處理流程就已經差不多說完了,不過這里還差一小步,就是syscall指令在進入到內核態之后,是如何找到entry_SYSCALL_64方法的:
它其實是注冊到了MSR_LSTAR寄存器里了,syscall指令在進入到內核態之后,會直接從這個寄存器里拿系統調用處理函數的地址,并開始執行。
系統調用內核態的邏輯處理就是這些。
下面我們用一個例子來演示下用戶態部分:
編譯并執行:
我們用syscall來執行write系統調用,寫的字符串為Hi\n,syscall執行完畢后,我們直接使用ret指令將write的返回結果當作程序的退出碼返回。
所以在上圖中,輸出了Hi,且程序的退出碼是3。
如果對上面的匯編不太理解,可以把它想像成下面這個樣子:
在這里,我們使用的是glibc中的write方法來執行該系統調用,其實該方法就是對syscall指令做的一層封裝,本質上使用的還是我們上面的匯編代碼。
這個例子到這里就結束了。
有沒有覺得不太盡興?
我們分析了這么多的代碼,最終就用了這么個小例子就結束了,不行,我們要再做點什么。
要不我們來自己寫個系統調用?
說干就干。
我們先在write系統調用下面定義一個我們自己的系統調用:
該方法很簡單,就是將參數加10,然后返回。
再把這個系統調用在syscall_64.tbl里注冊一下,編號為442:
編譯內核,等待執行。
我們再把上面寫的那個hi程序改下并編譯好:
然后在虛擬機中啟動新編譯的linux內核,并執行上面的程序:
看結果,正好就是20。
看完上述內容,你們對linux系統調用是如何實現的有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。