copy_{to,from}_user()的思考

引言

我們對copy_{to,from}_user()介面的使用應該是再熟悉不過吧。基本Linux書籍都會介紹它的作用。畢竟它是kernel space和user space溝通的橋梁。所有的資料互動都應該使用類似這種介面。所以，我們沒有理由不知道介面的作用。但是，我也曾經有過以下疑問。

1. 為什麼需要copy_{to,from}_user()，它究竟在背後為我們做了什麼？
2. copy_{to,from}_user()和memcpy()的區別是什麼，直接使用memcpy()可以嗎？
3. memcpy()替代copy_{to,from}_user()是不是一定會有問題？

一下子找回了當年困惑的自己。我所提出的每個問題，曾經我也思考過。還不止一次的思考，每一次都有不同的想法。當然是因為從一開始就我就沒有完全理解。現在又重新回到這個沉重的話題，繼續思考這曾經的問題。

溫馨提示：文章程式碼分析基於Linux-4.18.0，部分架構相關程式碼以ARM64為代表。

百家爭鳴

針對以上問題當然是先百度。百度對於該問題的部落格也是很多，足以看出這個問題肯定困惑著一大批Linux的愛好者。對於我的查閱結果來說，觀點主要分成以下兩種：

• copy_{to,from}_user()比memcpy()多了傳入地址合法性校驗。例如是否屬於使用者空間地址範圍。理論上說，核心空間可以直接使用使用者空間傳過來的指標，即使要做資料複製的動作，也可以直接使用memcpy()，事實上在沒有MMU的體系架構上，copy_{to,from}_user()最終的實現就是利用了memcpy()。但是對於大多數有MMU的平臺，情況就有了些變化：使用者空間傳過來的指標是在虛擬地址空間上的，它所指向的虛擬地址空間很可能還沒有真正對映到實際的物理頁面上。但是這又能怎樣呢？缺頁導致的異常會很透明地被核心予以修複（為缺頁的地址空間提交新的物理頁面），訪問到缺頁的指令會繼續執行彷彿什麼都沒有發生一樣。但這隻是使用者空間缺頁異常的行為，在核心空間這種缺頁異常必須被顯式地修複，這是由核心提供的缺頁異常處理函式的設計樣式決定的。其背後的思想是：在核心態，如果程式試圖訪問一個尚未被提交物理頁面的使用者空間地址，核心必須對此保持警惕而不能像使用者空間那樣毫無察覺。
• 如果我們確保使用者態傳遞的指標的正確性，我們完全可以用memcpy()函式替代copy_{to,from}_user()。經過一些試驗測試，發現使用memcpy()，程式的執行上並沒有問題。因此在確保使用者態指標安全的情況下，二者可以替換。

   

從各家部落格上，觀點主要集中在第一點。看起來第一點受到大家的廣泛認可。但是，註重實踐的人又得出了第二種觀點，畢竟是實踐出真知。真理究竟是是掌握在少數人手裡呢？還是群眾的眼睛是雪亮的呢？當然，我不否定以上任何一種觀點。也不能向你保證哪種觀點正確。因為，我相信即使是曾經無懈可擊的理論，隨著時間的推移或者特定情況的改變理論也可能不再正確。比如，牛頓的經典力學理論（好像扯得有點遠）。如果要我說人話，就是：隨著時間的推移，Linux的程式碼在不斷的變化。或許以上的觀點在曾經正確。當然，也可能現在還正確。下麵的分析就是我的觀點了。同樣，大家也是需要保持懷疑的態度。下麵我就拋磚引玉。

拋磚引玉

首先我們看下memcpy()和copy_{to,from}_user()的函式定義。引數幾乎沒有差別，都包含目的地址，源地址和需要複製的位元組size。

1. static __always_inline unsigned long __must_check
2. copy_to_user(void __user *to, const void *from, unsigned long n);
3.  
4. static __always_inline unsigned long __must_check
5. copy_from_user(void *to, const void __user *from, unsigned long n);
6.  
7. void *memcpy(void *dest, const void *src, size_t len);

 

但是，有一點我們肯定是知道的。那就是memcpy()沒有傳入地址合法性校驗。而copy_{to,from}_user()針對傳入地址進行類似下麵的合法性校驗（簡單說點，更多校驗詳情可以參考程式碼）。

• 如果從使用者空間copy資料到核心空間，使用者空間地址to及to加上copy的位元組長度n必須位於使用者空間地址空間。
• 如果從核心空間copy資料到使用者空間，當然也需要檢查地址的合法性。例如，是否越界訪問或者是不是程式碼段的資料等等。總之一切不合法地操作都需要立刻杜絕。

   

經過簡單的對比之後，我們再看看其他的差異以及一起探討下上面提出的2個觀點。我們先從第2個觀點說起。涉及實踐，我還是有點相信實踐出真知。從我測試的結果來說，實現結果分成兩種情況。

第一種情況的結果是：使用memcpy()測試，沒有出現問題，程式碼正常執行。測試程式碼如下（僅僅展示proc檔案系統下file_operations對應的read介面函式）：

1. static ssize_t test_read(struct file *file, char __user *buf,
2. size_t len, loff_t *offset)
3. {
4. memcpy(buf, “test\n”, 5); /* copy_to_user(buf, “test\n”, 5) */
5.  
6. return 5;
7. }

 

我們使用cat命令讀取檔案內容，cat會透過系統呼叫read呼叫test_read，並且傳遞的buf大小是4k。測試很順利，結果很喜人。成功地讀到了“test”字串。看起來，第2點觀點是沒毛病的。但是，我們還需要繼續驗證和探究下去。因為第1個觀點提到，“在核心空間這種缺頁異常必須被顯式地修複”。因此我們還需要驗證的情況是：如果buf在使用者空間已經分配虛擬地址空間，但是並沒有建立和物理記憶體的具體對映關係，這種情況下會出現核心態page fault。我們首先需要建立這種條件，找到符合的buf，然後測試。這裡我當然沒測啦。因為有測試結論（主要是因為我懶，構造這個條件我覺得比較麻煩）。這個測試是我的一個朋友，人稱宋老師的“阿助教”阿克曼大牛。他曾經做個這個實驗，並且得到的結論是：即使是沒有建立和物理記憶體的具體對映關係的buf，程式碼也可以正常執行。在核心態發生page fault，並被其修複（分配具體物理記憶體，填充頁表，建立對映關係）。同時，我從程式碼的角度分析，結論也是如此。

經過上面的分析，看起來好像是memcpy()也可以正常使用，鑒於安全地考慮建議使用copy_{to,from}_user()等介面。

第二種情況的結果是：以上的測試程式碼並沒有正常執行，並且會觸發kernel oops。當然本次測試和上次測試的kernel配置選項是不一樣的。這個配置項是CONFIG_ARM64_SW_TTBR0_PAN或者CONFIG_ARM64_PAN（針對ARM64平臺）。兩個配置選項的功能都是阻止核心態直接訪問使用者地址空間。只不過，CONFIG_ARM64_SW_TTBR0_PAN是軟體模擬實現這種功能，而CONFIG_ARM64_PAN是硬體實現功能（ARMv8.1擴充套件功能）。我們以CONFIG_ARM64_SW_TTBR0_PAN作為分析物件（軟體模擬才有程式碼提供分析）。BTW，如果硬體不支援，即使配置CONFIG_ARM64_PAN也沒用，只能使用軟體模擬的方法。核心Kconfig部分解釋如下。如果需要訪問使用者空間地址需要透過類似copy_{to,from}_user()的介面，否則會導致kernel oops。

1. config ARM64_SW_TTBR0_PAN
2. bool “Emulate Privileged Access Never using TTBR0_EL1 switching”
3. help
4. Enabling this option prevents the kernel from accessing
5. user–space memory directly by pointing TTBR0_EL1 to a reserved
6. zeroed area and reserved ASID. The user access routines
7. restore the valid TTBR0_EL1 temporarily.

 

在開啟CONFIG_ARM64_SW_TTBR0_PAN的選項後，測試以上程式碼就會導致kernel oops。原因就是核心態直接訪問了使用者空間地址。因此，在這種情況我們就不可以使用memcpy()。我們別無選擇，只能使用copy_{to,from}_user()。當然了，我們也不是沒有辦法使用memcpy()，但是需要額外的操作。如何操作呢？下一節為你揭曉。

刨根問底

既然提到了CONFIG_ARM64_SW_TTBR0_PAN的配置選項。當然我也希望瞭解其背後設計的原理。由於ARM64的硬體特殊設計，我們使用兩個頁表基地址暫存器ttbr0_el1和ttbr1_el1。處理器根據64 bit地址的高16 bit判斷訪問的地址屬於使用者空間還是核心空間。如果是使用者空間地址則使用ttbr0_el1，反之使用ttbr1_el1。因此，ARM64行程切換的時候，只需要改變ttbr0_el1的值即可。ttbr1_el1可以選擇不需要改變，因為所有的行程共享相同的核心空間地址。

當行程切換到核心態（中斷，異常，系統呼叫等）後，如何才能避免核心態訪問使用者態地址空間呢？其實不難想出，改變ttbr0_el1的值即可，指向一段非法的對映即可。因此，我們為此準備了一份特殊的頁表，該頁表大小4k記憶體，其值全是0。當行程切換到核心態後，修改ttbr0_el1的值為該頁表的地址即可保證訪問使用者空間地址是非法訪問。因為頁表的值是非法的。這個特殊的頁表記憶體透過連結指令碼分配。

1. #define RESERVED_TTBR0_SIZE (PAGE_SIZE)
2.  
3. SECTIONS
4. {
5. reserved_ttbr0 = .;
6. . += RESERVED_TTBR0_SIZE;
7. swapper_pg_dir = .;
8. . += SWAPPER_DIR_SIZE;
9. swapper_pg_end = .;
10. }

 

這個特殊的頁表和核心頁表在一起。和swapper_pg_dir僅僅差4k大小。reserved_ttbr0地址開始的4k記憶體空間的內容會被清零。

當我們進入核心態後會透過__uaccess_ttbr0_disable切換ttbr0_el1以關閉使用者空間地址訪問，在需要訪問的時候透過__uaccess_ttbr0_enable開啟使用者空間地址訪問。這兩個宏定義也不複雜，就以__uaccess_ttbr0_disable為例說明原理。其定義如下：

1. .macro __uaccess_ttbr0_disable, tmp1
2. mrs \tmp1, ttbr1_el1 // swapper_pg_dir (1)
3. bic \tmp1, \tmp1, #TTBR_ASID_MASK
4. sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before
5. // swapper_pg_dir (2)
6. msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1 (3)
7. isb
8. add \tmp1, \tmp1, #RESERVED_TTBR0_SIZE
9. msr ttbr1_el1, \tmp1 // set reserved ASID
10. isb
11. .endm

 

1. ttbr1_el1儲存的是核心頁表基地址，因此其值就是swapper_pg_dir。
2. swapper_pg_dir減去RESERVED_TTBR0_SIZE就是上面描述的特殊頁表。
3. 將ttbr0_el1修改指向這個特殊的頁表基地址，當然可以保證後續訪問使用者地址都是非法的。

__uaccess_ttbr0_disable對應的C語言實現可以參考這裡。如何允許核心態訪問使用者空間地址呢？也很簡單，就是__uaccess_ttbr0_disable的反操作，給ttbr0_el1賦予合法的頁表基地址。這裡就不必重覆了。我們現在需要知道的事實就是，在配置CONFIG_ARM64_SW_TTBR0_PAN的情況下，copy_{to,from}_user()介面會在copy之前允許核心態訪問使用者空間，併在copy結束之後關閉核心態訪問使用者空間的能力。因此，使用copy_{to,from}_user()才是正統做法。主要體現在安全性檢查及安全訪問處理。這裡是其比memcpy()多的第一個特性，後面還會介紹另一個重要特性。

現在我們可以解答上一節中遺留的問題。怎樣才能繼續使用memcpy()？現在就很簡單了，在memcpy()呼叫之前透過uaccess_enable_not_uao()允許核心態訪問使用者空間地址，呼叫memcpy()，最後透過uaccess_disable_not_uao()關閉核心態訪問使用者空間的能力。

未雨綢繆

以上的測試用例都是建立在使用者空間傳遞合法地址的基礎上測試的，何為合法的使用者空間地址？使用者空間透過系統呼叫申請的虛擬地址空間包含的地址範圍，即是合法的地址（不論是否分配物理頁面建立對映關係）。既然要寫一個介面程式，當然也要考慮程式的健壯性，我們不能假設所有的使用者傳遞的引數都是合法的。我們應該預判非法傳參情況的發生，並提前做好準備，這就是未雨綢繆。

我們首先使用memcpy()的測試用例，隨機傳遞一個非法的地址。經過測試發現：會觸發kernel oops。繼續使用copy_{to,from}_user()替代memcpy()測試。測試發現：read()僅僅是傳回錯誤，但不會觸發kernel oops。這才是我們想要的結果。畢竟，一個應用程式不應該觸發kernel oops。這種機制的實現原理是什麼呢？

我們以copy_to_user()為例分析。函式呼叫流程如下：

1. copy_to_user()->_copy_to_user()->raw_copy_to_user()->__arch_copy_to_user()

 

__arch_copy_to_user()在ARM64平臺是彙編程式碼實現，這部分程式碼很關鍵。

1. end .req x5
2. ENTRY(__arch_copy_to_user)
3. uaccess_enable_not_uao x3, x4, x5
4. add end, x0, x2
5. #include “copy_template.S”
6. uaccess_disable_not_uao x3, x4
7. mov x0, #0
8. ret
9. ENDPROC(__arch_copy_to_user)
10.  
11. .section .fixup,“ax”
12. .align 2
13. 9998: sub x0, end, dst // bytes not copied
14. ret
15. .previous

 

1. uaccess_enable_not_uao和uaccess_disable_not_uao是上面說到的核心態訪問使用者空間的開關。
2. copy_template.S檔案是彙編實現的memcpy()的功能，稍後看看memcpy()的實現程式碼就清楚了。
3. .section .fixup,“ax”定義一個section，名為“.fixup”，許可權是ax（‘a’可重定位的段，‘x’可執行段）。9998標號處的指令就是“未雨綢繆”的善後處理工作。還記得copy_{to,from}_user()傳回值的意義嗎？傳回0代表copy成功，否則傳回剩餘沒有copy的位元組數。這行程式碼就是計算剩餘沒有copy的位元組數。當我們訪問非法的使用者空間地址的時候，就一定會觸發page fault。這種情況下，核心態發生的page fault並傳回的時候並沒有修複異常，所以肯定不能傳回發生異常的地址繼續執行。所以，系統可以有2個選擇：第1個選擇是kernel oops，並給當前行程傳送SIGSEGV訊號；第2個選擇是不傳回出現異常的地址執行，而是選擇一個已經修複的地址傳回。如果使用的是memcpy()就只有第1個選擇。但是copy_{to,from}_user()可以有第2個選擇。.fixup段就是為了實現這個修複功能。當copy過程中出現訪問非法使用者空間地址的時候，do_page_fault()傳回的地址變成9998標號處，此時可以計算剩餘未copy的位元組長度，程式還可以繼續執行。

對比前面分析的結果，其實__arch_copy_to_user()可以近似等效如下關係。

1. uaccess_enable_not_uao();
2. memcpy(ubuf, kbuf, size); == __arch_copy_to_user(ubuf, kbuf, size);
3. uaccess_disable_not_uao();

 

先插播一條訊息，解釋copy_template.S為何是memcpy()。memcpy()在ARM64平臺是由彙編程式碼實現。其定義在arch/arm64/lib/memcpy.S檔案。

1. .weak memcpy
2. ENTRY(__memcpy)
3. ENTRY(memcpy)
4. #include “copy_template.S”
5. ret
6. ENDPIPROC(memcpy)
7. ENDPROC(__memcpy)

 

所以很明顯，memcpy()和__memcpy()函式定義是一樣的。並且memcpy()函式宣告是weak，因此可以重寫memcpy()函式（扯得有點遠）。再扯一點，為何使用彙編呢？為何不使用lib/string.c檔案的memcpy()函式呢？當然是為了最佳化memcpy() 的執行速度。lib/string.c檔案的memcpy()函式是按照位元組為單位進行copy（再好的硬體也會被粗糙的程式碼毀掉）。但是現在的處理器基本都是32或者64位，完全可以4 bytes或者8 bytes甚至16 bytes copy（考慮地址對齊的情況下）。可以明顯提升執行速度。所以，ARM64平臺使用彙編實現。這部分知識可以參考這篇部落格《ARM64 的 memcpy 最佳化與實現》。

下麵繼續進入正題，再重覆一遍：核心態訪問使用者空間地址，如果觸發page fault，只要使用者空間地址合法，核心態也會像什麼也沒有發生一樣修複異常（分配物理記憶體，建立頁表對映關係）。但是如果訪問非法使用者空間地址，就選擇第2條路，嘗試救贖自己。這條路就是利用.fixup和__ex_table段。如果無力迴天只能給當前行程傳送SIGSEGV訊號。並且，輕則kernel oops，重則panic（取決於kernel配置選項CONFIG_PANIC_ON_OOPS）。在核心態訪問非法使用者空間地址的情況下，do_page_fault()最終會跳轉no_context標號處的__do_kernel_fault()。

1. static void __do_kernel_fault(unsigned long addr, unsigned int esr,
2. struct pt_regs *regs)
3. {
4. /*
5. * Are we prepared to handle this kernel fault?
6. * We are almost certainly not prepared to handle instruction faults.
7. */
8. if (!is_el1_instruction_abort(esr) && fixup_exception(regs))
9. return;
10. /* … */
11. }

 

fixup_exception()繼續呼叫search_exception_tables()，其透過查詢__ex_table段。__ex_table段儲存exception table，每個entry儲存著異常地址及其對應修複的地址。例如上述的9998: sub x0, end, dst指令的地址就會被找到並修改do_page_fault()函式的傳回地址，以達到跳轉修複的功能。其實查詢過程是根據出問題的地址addr，查詢__ex_table段（exception table）是否有對應的exception table entry，如果有就代表可以被修複。由於32位處理器和64位處理器實現方式有差別，因此我們先從32位處理器異常表的實現原理說起。

__ex_table段的首尾地址分別是__start___ex_table和__stop___ex_table（定義在include/asm-generic/vmlinux.lds.h。這段記憶體可以看作是一個陣列，陣列的每個元素都是struct exception_table_entry型別，其記錄著異常發生地址及其對應的修複地址。

1. exception tables
2. __start___ex_table –> +—————+
3. | entry |
4. +—————+
5. | entry |
6. +—————+
7. | … |
8. +—————+
9. | entry |
10. +—————+
11. | entry |
12. __stop___ex_table –> +—————+

 

在32位處理器上，struct exception_table_entry定義如下：

1. struct exception_table_entry {
2. unsigned long insn, fixup;
3. };

 

有一點需要明確，在32位處理器上，unsigned long是4 bytes。insn和fixup分別儲存異常發生地址及其對應的修複地址。根據異常地址ex_addr查詢對應的修複地址（未找到傳回0），其示意程式碼如下：

1. unsigned long search_fixup_addr32(unsigned long ex_addr)
2. {
3. const struct exception_table_entry *e;
4.  
5. for (e = __start___ex_table; e < __stop___ex_table; e++)
6. if (ex_addr == e->insn)
7. return e->fixup;
8.  
9. return 0;
10. }

 

在32位處理器上，建立exception table entry相對簡單。針對copy_{to,from}_user()彙編程式碼中每一處使用者空間地址訪問的指令都會建立一個entry，並且insn儲存當前指令對應的地址，fixup儲存修複指令對應的地址。

當64位處理器開始發展起來，如果我們繼續使用這種方式，勢必需要2倍於32位處理器的記憶體儲存exception table（因為儲存一個地址需要8 bytes）。所以，kernel換用另一種方式實現。在64處理器上，struct exception_table_entry定義如下：

1. struct exception_table_entry {
2. int insn, fixup;
3. };

 

每個exception table entry佔用的記憶體和32位處理器情況一樣，因此記憶體佔用不變。但是insn和fixup的意義發生變化。insn和fixup分別儲存著異常發生地址及修複地址相對於當前結構體成員地址的偏移（有點拗口）。例如，根據異常地址ex_addr查詢對應的修複地址（未找到傳回0），其示意程式碼如下：

1. unsigned long search_fixup_addr64(unsigned long ex_addr)
2. {
3. const struct exception_table_entry *e;
4.  
5. for (e = __start___ex_table; e < __stop___ex_table; e++)
6. if (ex_addr == (unsigned long)&e->insn + e->insn)
7. return (unsigned long)&e->fixup + e->fixup;
8.  
9. return 0;
10. }

 

因此，我們的關註點就是如何去構建exception_table_entry。我們針對每個使用者空間地址的記憶體訪問都需要建立一個exception table entry，並插入__ex_table段。例如下麵的彙編指令（彙編指令對應的地址是隨意寫的，不用糾結對錯。理解原理才是王道）。

1. 0xffff000000000000: ldr x1, [x0]
2. 0xffff000000000004: add x1, x1, #0x10
3. 0xffff000000000008: ldr x2, [x0, #0x10]
4. /* … */
5. 0xffff000040000000: mov x0, #0xfffffffffffffff2 // -14
6. 0xffff000040000004: ret

 

假設x0暫存器儲存著使用者空間地址，因此我們需要對0xffff000000000000地址的彙編指令建立一個exception table entry，並且我們期望當x0是非法使用者空間地址時，跳轉傳回的修複地址是0xffff000040000000。為了計算簡單，假設這是建立第一個entry，__start___ex_table值是0xffff000080000000。那麼第一個exception table entry的insn和fixup成員的值分別是：0x80000000和0xbffffffc（這兩個值都是負數）。因此，針對copy_{to,from}_user()彙編程式碼中每一處使用者空間地址訪問的指令都會建立一個entry。所以0xffff000000000008地址處的彙編指令也需要建立一個exception table entry。

所以，如果核心態訪問非法使用者空間地址究竟發生了什麼？上面的分析流程可以總結如下：

1.訪問非法使用者空間地址:0xffff000000000000: ldr x1, [x0]
2.MMU觸發異常
3.CPU呼叫do_page_fault()
4.do_page_fault()呼叫search_exception_table()（regs->pc == 0xffff000000000000）
5.檢視__ex_table段，尋找0xffff000000000000 並且傳回修複地址0xffff000040000000
6.do_page_fault()修改函式傳回地址（regs->pc = 0xffff000040000000）並傳回
7.程式繼續執行，處理出錯情況
8.修改函式傳回值x0 = -EFAULT (-14) 並傳回（ARM64透過x0傳遞函式傳回值）

總結

到了回顧總結的時候，copy_{to,from}_user()的思考也到此結束。我們來個總結結束此文。

• 無論是核心態還是使用者態訪問合法的使用者空間地址，當虛擬地址並未建立物理地址的對映關係的時候，page fault的流程幾乎一樣，都會幫助我們申請物理記憶體並建立對映關係。所以這種情況下memcpy()和copy_{to,from}_user()是類似的。
• 當核心態訪問非法使用者空間地址的時候，透過.fixup和__ex_table兩個段的幫助嘗試修複異常。這種修複異常並不是建立地址對映關係，而是修改do_page_fault()傳回地址。memcpy()由於沒有建立這樣的段，所以memcpy()無法做到這點。
• 在使能CONFIG_ARM64_SW_TTBR0_PAN或者CONFIG_ARM64_PAN（硬體支援的情況下才有效）的時候，我們只能使用copy_{to,from}_user()這種介面，直接使用memcpy()是不行的。

   

最後，我想說，即使在某些情況下memcpy()可以正常工作。但是，這也是不推薦的，不是良好的程式設計習慣。在使用者空間和核心空間資料互動上，我們必須使用類似copy_{to,from}_user()的介面。為什麼類似呢？因為還有其他的介面用於核心空間和使用者空間資料互動，只是沒有copy_{to,from}_user()出名。例如：{get,put}_user()。