gVisor 是什麼？可以解決什麼問題？

以非特權使用者執行的gVisor通過截獲應用程式的系統呼叫，將應用程式和核心之間完全隔離。gVisor沒有簡單的把應用程式發出的系統呼叫直接作用到核心，而是實現了大多數的系統呼叫，通過對系統呼叫模擬，讓應用程式間接的訪問到系統資源。gVisor模擬系統呼叫本身時對作業系統執行系統呼叫，通過使用Seccomp對這些系統呼叫做過濾。那麼gVisor是如何截獲應用程式的系統呼叫的呢？

gVisor截獲系統呼叫

gVisor存在兩種執行模式，這次分享只介紹了基於Ptrace的gVisor。

為了理解gVisor如何攔截系統呼叫，需要先了解一下Ptrace：Ptrace是Linux提供的一個系統呼叫介面，通過Ptrace，可以在兩個程序之間建立Tracer和Tracee之間的關係。Tracer可以控制Tracee，例如當Tracee收到訊號的時候主動進入stopped狀態，此時Tracer可以選擇是否對Tracee做一些操作（比如設定Tracee的暫存器上下文或者記憶體中內容等），在操作執行後，Tracer可以選擇是否讓Tracee繼續執行。

Tracee除了可以在接受到訊號時候進入stopped狀態外，也可以被Tracer告知在即將進入系統呼叫時或者即將離開系統呼叫時進入stopped狀態。具體說Ptrace可以通過PTRACE_SYSEMU控制Tracee在即將進去系統調動時stop。gVisor也正是通過該命令來截獲應用程式的系統呼叫。

Sentry是通過Ptrace來控制應用程式，那麼應用程式是如何變為Tracee的呢？

將應用程式變成Tracee的

下圖是gVisor控制應用程式的程序關係：

當gVisor以Docker的Runtime啟動的時候，可以看到類似的程序間關係：docker-containerd-shim是容器的啟動器；sentry是gVisor用於截獲系統呼叫模擬核心的程式，他也正是Tracer。Stub可以暫時不用理會，stub的子程序正是我們想要放到Sandbox裡的應用程式。Sentry建立stub，隨後stub建立應用程式程序，sentry通過Ptrace attach到了stub和應用程式上。當應用程式在將要執行系統呼叫的時候會主動stop，此時也正是sentry攔截和模擬系統呼叫的點。

這跟用gdb除錯程式C/C++程式類似，通過命令列給gdb指定一個要除錯的目標程式的時候，該程式會以子程序的方式執行，gdb作為Tracer attach到應用程式上來對應用程式進行控制。類似gdb，sentry也以類似的方式啟動應用程式，只是sentry先啟動了一個stub，然後讓stub以它的子程序方式啟動了應用程式。

應用程式被建立並變為Tracee後，接下來就是sentry如何完成應用程式的啟動流程了。

啟動應用程式

應用程式被初始attach到sentry後，sentry負責啟動應用程式。

在作業系統啟動應程式場景裡，應用程式的二進位制檔案由作業系統載入，譬如分配虛擬記憶體空間用來存放二進位制中的程式碼段、資料段、共享庫或者初始化應用程式的棧空間。gVisor啟動應用程式的場景下，類似的過程由sentry完成：

為了瞭解sentry是如何初始化應用程式的虛擬記憶體空間，需要先了解一下上文提到的stub程序。

Stub程序的一個重要的作用是作為應用程式的初始模板，以該模板建立應用程式。事實上stub作為sentry的子程序，在啟動後會主動將虛擬記憶體地址空間裡幾乎所有的memory region（通過檢視/proc/${pid}/maps檢視一個程序虛擬記憶體地址空間裡的所有memory region）甚至將程式碼段和資料段也unmmap掉了。只保留兩個memory region：

其中第一個region存放了最簡化的程式碼，即上圖中第一個段，執行該程式碼甚至不需要棧空間，所以連棧段也被unmap掉了。

這樣的空洞的虛擬內容地址空間正好可以作為一個模板虛擬記憶體地址空間。當stub以子程序的方式啟動應用程式後，應用程式的虛擬記憶體地址空間的layout與stub的一樣。應用程式在創建出來後會立即被sentry attach，此時正是sentry做應用程式初始化的過程：sentry初始設定應用程式的RIP（指令執行暫存器）的初始值為應用程式二進位制中讀出來的應用程式入口地址，該地址一般位於應用程式虛擬地址空間的較低位置，並通過PTRACE_SYSEMU指示應用程式開始執行，直到遇到以下兩種事件的時候進入stop狀態：

1. 將要執行一個系統呼叫

2. 收到了來自核心或者程序發給它的訊號

因為應用程式的初始執行位置在使用者態的虛擬記憶體地址裡沒有對應的memory region，所以應用程式會收到來自核心發來的SIGSEGV訊號（段錯誤）。這裡的場景非常類似通常的page fault，當一個應用程式試圖訪問的地址位於某個虛擬記憶體地址段內，但該段沒有對應實體記憶體頁的時候，作業系統會因此陷入page fault，在page fault的handler中為該虛擬記憶體地址段對映物理頁。

事實上，在sentry在啟動應用程式執行環境之前，已經應用程式“分配”了一個虛擬記憶體地址段（這個分配並不是使用mmap或者brk真正的在應用程式的虛擬地址空間中分配地址段，該分配是一個提前佔位）。上面說到當應用程式執行指令地址上因為沒有實際分配虛擬記憶體地址段，所以收到來自核心的SIGSEGV，並且進入stopped狀態，此時sentry會通過mmap在該地址上真實分配一個虛擬地址記憶體段（類比作業系統為虛擬記憶體地址段上分配物理頁），並且因為mmap的原始檔是二進位制檔案本身，所以當sentry在處理完SIGSEGV指示應用程式繼續執行的後，應用程式將實際執行到該二進位制中的程式碼。

至此應用程式就已經啟動起來了。接下來需要了解就是sentry如何控制應用程式的執行了。

應用程式的執行

應用程式被啟動起來後，在執行的過程中可能會陸續遇到新的SIGSEGV（譬如程式讀寫地址段，或者棧空間的擴充套件），或者執行系統呼叫。

在“應用程式如何被啟動”裡實際上已經描述了SIGSEGV訊號處理的一種場景，即只讀地址且有對映檔案的場景，其他的場景譬如匿名地址段或者棧空間的區別在於該地址段沒有mmap實際的檔案，而是mmap了一個sentry提前準備好的“空白”檔案中。

在“gVisor如何攔截系統呼叫”中描述了系統呼叫的攔截，當應用程式在進入系統呼叫之前會自動進入stopped狀態，此時sentry讀取應用程式的系統呼叫號以及系統呼叫入參，試圖模擬該系統呼叫。以檔案的讀sys_read為例，sys_read的作用是找到指定的檔案，開啟並讀取檔案內容，並將記憶體寫入到應用程式系統呼叫引數指定的虛擬記憶體地址上。Sentry在接到這個的系統呼叫時，會將檔案讀取請求通過9p協議發給之前提到的gofer程序（sentry和gofer之間有建立socket pair傳輸9p協議），由gofer程序執行真正的檔案讀取且將讀到的內容通過9p協議返回給sentry。sentry把讀取到的檔案內容寫入到應用程式的虛擬記憶體中（如果該地址沒有對應的虛擬記憶體地址段，則分配後再複製），隨後sentry將系統呼叫的實際模擬結果寫入到應用程式的暫存器中，然後讓應用程式繼續執行。恢復執行後的應用程式因為得到了系統呼叫的結果，所以在應用程式在分不清實際上系統呼叫是直接由作業系統執行了還是由sentry做的模擬的情況下，系統呼叫得到了滿足。

應用程式的訪問控制

“應用程式的執行”中對於檔案讀系統呼叫處理的描述實際上也描述了對應用程式檔案系統訪問的控制，實際上在“應用程式啟動”中為了省略的根檔案系統掛載的描述，在根檔案系統掛載的模擬中也涉及到了通過9p協議對檔案系統的訪問。檔案寫的處理也非常類似。

除了檔案讀寫外，還有很多其他的系統呼叫，譬如共享記憶體或其他IPC，鎖，建立執行緒或者程序，傳送訊號，socket，execv，epoll，eventfd，pid namespace等，gVisor都進行了模擬，涉及到了作業系統的方方面面。這裡僅僅介紹了socket相關的系統呼叫：

Sentry在使用者態實現了基本的TCP/IP協議棧，在啟動應用程式之前，gVisor會啟動一個臨時的start程序，在start程序會進入到docker建立的network namespace，start程序從該network namespace中獲取veth pair中屬於gVisor的一端的veth裝置，建立AF_PACKET的socket繫結到該veth裝置上來接管該裝置上的網路流量（同時也將ip從該裝置上去掉了），並將該socket傳遞給sentry程序。後續當sentry截獲了應用程式的socket系統呼叫後，最終通過該socket將網路包實際從veth裝置上傳送出去；從該veth裝置上接收到的網路包在經過sentry網路協議棧後遞交給應用程式的socket層。