LWN：在另一個進程的地址空間內(nèi)執(zhí)行代碼！

關(guān)注了就能看到更多這么棒的文章哦～

Running code within another process's address space

By Jonathan Corbet
April 16, 2021
DeepL assisted translation
https://lwn.net/Articles/852662/

描述一個進程的時候，總會提到它的關(guān)鍵資源之一：地址空間（address space），這是一組映射關(guān)系用來決定任意一段內(nèi)存地址（memory address）在該進程中是如何使用的。通常來說地址空間對它所屬的進程來說是私有的，但在有些情況下，一個進程需要對另一個進程的內(nèi)存區(qū)域進行修改，比如交互式的 debugger 調(diào)試器這種情況。ptrace()系統(tǒng)調(diào)用使得這種行為變得可行了，但還是很慢，有時候不那么容易使用，所以長期以來人們一直在尋找其他更好的方案。Andrei Vagin 最近提出的 process_vm_exec() 供大家 review，就是希望作為一種可能的解決方案。

事實上，對于某些場景來說已經(jīng)有了很好的替代 ptrace()的方案。在 2011 年，3.2 版本內(nèi)核中合入了一個名為 cross-memory attach system calls 的方案，增加的系統(tǒng)調(diào)用名為 process_vm_readv()和 process_vm_writev()。正如它們的名字所示，它們允許一個進程從另一個進程的 memory 中進行讀取和寫入。這些系統(tǒng)調(diào)用滿足了許多場景下的需求，但有時候需要對另一個進程的地址空間進行更多的訪問，這時就顯得不夠用了?？雌饋沓嗽谀繕诉M程地址空間內(nèi)運行代碼之外，沒有其他選擇。

Vagin 的 patch set 給出了幾個例子，來說明這種訪問會很有用。User-mode kernel（用戶模式 Linux kernel）中，比如User-mode Linux 和 gVisor，必須能夠攔截由沙盒中的進程發(fā)出的系統(tǒng)調(diào)用，并可能需要在該進程的地址空間內(nèi)運行這段代碼。Checkpoint/Restore in User space（用戶空間中快照以及恢復(fù)）項目需要能夠深入到一個進程中來提取 checkpoint 所需的所有信息。目前這兩種情況都是用 ptrace() 來處理的，但是我們希望有更好的、更快的替代品。

Vagin 提出的替代方案是一個新的系統(tǒng)調(diào)用：

int process_vm_exec(pid_t pid, struct sigcontext uctx, unsigned long flags,
      siginfo_t siginfo, sigset_t *sigmask, size_t sizemask);

調(diào)用成功的話將導(dǎo)致調(diào)用進程的地址空間變成 pid 指定的這個進程的地址空間。Patch 的說明郵件中指出，使用 pidfd 可能更好，但這將會使得這個系統(tǒng)調(diào)用與 process_vm_readv()和 process_vm_writev()不再一致了。在從新的地址空間恢復(fù)代碼執(zhí)行之前，uctx 中的值被用來加載處理器的寄存器（包括當前指令的指針）。這個步驟非常重要，因為在新的地址空間如果使用之前的指令指針很可能會出問題。

如果 flags 為 0，process_vm_exec()將改變地址空間，然后按照 uctx 的指示恢復(fù)執(zhí)行，持續(xù)到進程進行系統(tǒng)調(diào)用或收到 signal 為止。這兩種情況都會恢復(fù)到舊的地址空間，process_vm_exec()將終止執(zhí)行并返回給調(diào)用者。siginfo 結(jié)構(gòu)描述了打斷另一個地址空間執(zhí)行的事件是什么，如果是一個系統(tǒng)調(diào)用 e 的話，siginfo 會被設(shè)置成好像收到了 SIGSYS 信號一樣。

相反，如果 flags 里有設(shè)置 PROCESS_VM_EXEC_SYSCALL，那么這個調(diào)用的目的是在目標進程的地址空間中調(diào)用一個系統(tǒng)調(diào)用。在這種情況下，uctx 應(yīng)該在合適的寄存器中配置好系統(tǒng)調(diào)用號及其參數(shù)，就像發(fā)生過真正的系統(tǒng)調(diào)用一樣。在系統(tǒng)調(diào)用的過程中，地址空間將被切換，然后在返回給調(diào)用者之前被恢復(fù)。

這組 patch 是作為一個原型來發(fā)布的，目的是希望得到大家對這種 API 反饋意見。Jann Horn 很快就回應(yīng)說，這個新提出的系統(tǒng)調(diào)用似乎并不適合所述的應(yīng)用場景，它對一個應(yīng)用場景來說做了太多工作，對另一個用例來說又還不夠。對于在不同的地址空間內(nèi)運行代碼的情況（如 User-mode Linux），他建議，不需要創(chuàng)建一個全新的進程，可能更好的做法是有一個系統(tǒng)調(diào)用來允許單獨創(chuàng)建出新的地址空間。不過，對于 checkpoint/restore 的情況，可能仍然需要訪問進程中除了地址空間之外的資源，盡管他沒有明確指出這些資源可能是什么。Vagin 回應(yīng)說，一個相對通用的系統(tǒng)調(diào)用似乎比創(chuàng)建多個分門別類的的系統(tǒng)調(diào)用要更好，哪怕這個通用系統(tǒng)調(diào)用并不完全適合所有應(yīng)用場景。

不過，F(xiàn)lorian Weimer 確實想到了另一種資源，會對 GNU C 庫很有好處。Linux 實現(xiàn) setuid()的方式和 POSIX 的要求是有區(qū)別的。Linux 只會改變當前調(diào)用線程的憑證信息（credential），而 POSIX 規(guī)定應(yīng)該要改變這個進程中所有線程的憑證信息。目前，glibc 是通過向所有線程發(fā)送信號從而在 Linux 上按 POSIX 語義實現(xiàn)，這樣它們就可以一起調(diào)用 setuid()，這種方案不是很理想。如果能在每個線程的上下文中調(diào)用 setuid()，而不用實際打斷線程，那就最好了。他說，這樣的功能對于實現(xiàn) memory barrier 也很有用。

一方面希望創(chuàng)造一個在某些情況下有用的功能，另一方面又試圖解決更大、更復(fù)雜的問題，這兩種需求之間顯然存在一些矛盾。在這種情況下，開發(fā)者必須謹慎選擇他們后續(xù)的道路。如果試圖做得太多，那么會非常有效地阻止其進入 mainline kernel，反而一點幫助也沒有了。目前看來 process_vm_exec() 今后前景尚不清楚。它可能最終會被接受，但在這之前可能需要進行巨大的改變。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～