引言
我們對copy_{to,from}_user()介面的使用應該是再熟悉不過吧，基本Linux書籍都會介紹它的作用，畢竟它是kernel space和user space溝通的橋梁，所有的資料互動都應該使用類似這種介面，所以，我們沒有理由不知道介面的作用，但是，我也曾經有過以下疑問，
為什么需要copy_{to,from}_user()，它究竟在背后為我們做了什么？
copy_{to,from}_user()和memcpy()的區別是什么，直接使用memcpy()可以嗎？
memcpy()替代copy_{to,from}_user()是不是一定會有問題？
一下子找回了當年困惑的自己，我所提出的每個問題，曾經我也思考過，還不止一次的思考，每一次都有不同的想法，當然是因為從一開始就我就沒有完全理解，現在又重新回到這個沉重的話題，繼續思考這曾經的問題，
溫馨提示：文章代碼分析基于Linux-4.18.0，部分架構相關代碼以ARM64為代表，
百家爭鳴
針對以上問題當然是先百度，百度對于該問題的博客也是很多，足以看出這個問題肯定困惑著一大批Linux的愛好者，對于我的查閱結果來說，觀點主要分成以下兩種：
copy_{to,from}_user()比memcpy()多了傳入地址合法性校驗，例如是否屬于用戶空間地址范圍，理論上說，內核空間可以直接使用用戶空間傳過來的指標，即使要做資料拷貝的動作，也可以直接使用memcpy()，事實上在沒有MMU的體系架構上，copy_{to,from}_user()最終的實作就是利用了mencpy()，但是對于大多數有MMU的平臺，情況就有了些變化：用戶空間傳過來的指標是在虛擬地址空間上的，它所指向的虛擬地址空間很可能還沒有真正映射到實際的物理頁面上，但是這又能怎樣呢？缺頁導致的例外會很透明地被內核予以修復（為缺頁的地址空間提交新的物理頁面），訪問到缺頁的指令會繼續運行仿佛什么都沒有發生一樣，但這只是用戶空間缺頁例外的行為，在內核空間這種缺頁例外必須被顯式地修復，這是由內核提供的缺頁例外處理函式的設計模式決定的，其背后的思想是：在內核態，如果程式試圖訪問一個尚未被提交物理頁面的用戶空間地址，內核必須對此保持警惕而不能像用戶空間那樣毫無察覺，
如果我們確保用戶態傳遞的指標的正確性，我們完全可以用memcpy()函式替代copy_{to,from}_user()，經過一些試驗測驗，發現使用memcpy()，程式的運行上并沒有問題，因此在確保用戶態指標安全的情況下，二者可以替換，
從各家博客上，觀點主要集中在第一點，看起來第一點受到大家的廣泛認可，但是，注重實踐的人又得出了第二種觀點，畢竟是實踐出真知，真理究竟是是掌握在少數人手里呢？還是群眾的眼睛是雪亮的呢？當然，我不否定以上任何一種觀點，也不能向你保證哪種觀點正確，因為，我相信即使是曾經無懈可擊的理論，隨著時間的推移或者特定情況的改變理論也可能不再正確，比如，牛頓的經典力學理論（好像扯得有點遠），如果要我說人話，就是：隨著時間的推移，Linux的代碼在不斷的變化，或許以上的觀點在曾經正確，當然，也可能現在還正確，下面的分析就是我的觀點了，同樣，大家也是需要保持懷疑的態度，下面我就拋磚引玉，
拋磚引玉
首先我們看下memcpy()和copy_{to,from}_user()的函式定義，引數幾乎沒有差別，都包含目的地址，源地址和需要復制的位元組size，
static __always_inline unsigned long __must_check
copy_to_user(void __user *to, const void *from, unsigned long n);
static __always_inline unsigned long __must_check
copy_from_user(void *to, const void __user *from, unsigned long n);
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介面函式）：
static ssize_t test_read(struct file *file, char __user *buf,
size_t len, loff_t *offset)
{
memcpy(buf, "test\n", 5); /* copy_to_user(buf, "test\n", 5) */
return 5;
}我們使用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也沒用，只能使用軟體仿真的方法，如果需要訪問用戶空間地址需要通過類似copy_{to,from}_user()的介面，否則會導致kernel oops，
在打開CONFIG_ARM64_SW_TTBR0_PAN的選項后，測驗以上代碼就會導致kernel oops，原因就是內核態直接訪問了用戶空間地址，因此，在這種情況我們就不可以使用memcpy()，我們別無選擇，只能使用copy_{to,from}_user()，
為什么我們需要PAN（Privileged Access Never）功能呢？原因可能是用戶空間和內核空間資料互動上容易引入安全問題，所以我們就不讓內核空間輕易訪問用戶空間，如果非要這么做，就必須通過特定的介面關閉PAN，另一方面，PAN功能可以更加規范化內核態和用戶態資料互動的介面使用，在使能PAN功能的情況下，可以迫使內核或者驅動開發者使用copy_{to,from}_user()等安全介面，提升系統的安全性，類似memcpy()非規范操作，kernel就oops給你看，
由于編程的不規范而引入安全漏洞，例如：Linux內核漏洞CVE-2017-5123可以提升權限，該漏洞的引入原因就是是缺少access_ok()檢查用戶傳遞地址的合法性，因此，為了避免自己撰寫的代碼引入安全問題，針對內核空間和用戶空間資料互動上，我們要格外當心，
刨根問底
既然提到了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的值為該頁表的地址即可保證訪問用戶空間地址是非法訪問，因為頁表的值是非法的，這個特殊的頁表記憶體通過鏈接腳本分配，
#define RESERVED_TTBR0_SIZE (PAGE_SIZE)
SECTIONS
{
reserved_ttbr0 = .;
. += RESERVED_TTBR0_SIZE;
swapper_pg_dir = .;
. += SWAPPER_DIR_SIZE;
swapper_pg_end = .;
}這個特殊的頁表和內核頁表在一起，和swapper_pg_dir僅僅差4k大小，reserved_ttbr0地址開始的4k記憶體空間的內容會被清零，
當我們進入內核態后會通過__uaccess_ttbr0_disable切換ttbr0_el1以關閉用戶空間地址訪問，在需要訪問的時候通過_uaccess_ttbr0_enable打開用戶空間地址訪問，這兩個宏定義也不復雜，就以_uaccess_ttbr0_disable為例說明原理，其定義如下：
.macro __uaccess_ttbr0_disable, tmp1
mrs \tmp1, ttbr1_el1 // swapper_pg_dir (1)
bic \tmp1, \tmp1, #TTBR_ASID_MASK
sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before
// swapper_pg_dir (2)
msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1 (3)
isb
add \tmp1, \tmp1, #RESERVED_TTBR0_SIZE
msr ttbr1_el1, \tmp1 // set reserved ASID
isb
.endm
ttbr1_el1存盤的是內核頁表基地址，因此其值就是swapper_pg_dir，
swapper_pg_dir減去RESERVED_TTBR0_SIZE就是上面描述的特殊頁表，
將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()為例分析，函式呼叫流程是：
copy_to_user()->_copy_to_user()->raw_copy_to_user()->__arch_copy_to_user()_arch_copy_to_user()在ARM64平臺是匯編代碼實作，這部分代碼很關鍵，
end .req x5
ENTRY(__arch_copy_to_user)
uaccess_enable_not_uao x3, x4, x5
add end, x0, x2
#include "copy_template.S"
uaccess_disable_not_uao x3, x4
mov x0, #0
ret
ENDPROC(__arch_copy_to_user)
.section .fixup,"ax"
.align 2
9998: sub x0, end, dst // bytes not copied
ret
.previous
uaccess_enable_not_uao和uaccess_disable_not_uao是上面說到的內核態訪問用戶空間的開關，
copy_template.S檔案是匯編實作的memcpy()的功能，稍后看看memcpy()的實作代碼就清楚了，
.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()可以近似等效如下關系，
uaccess_enable_not_uao();
memcpy(ubuf, kbuf, size); == __arch_copy_to_user(ubuf, kbuf, size);
uaccess_disable_not_uao();先插播一條訊息，解釋copy_template.S為何是memcpy()，memcpy()在ARM64平臺是由匯編代碼實作，其定義在arch/arm64/lib/memcpy.S檔案，
.weak memcpy
ENTRY(__memcpy)
ENTRY(memcpy)
#include "copy_template.S"
ret
ENDPIPROC(memcpy)
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()，
static void __do_kernel_fault(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
/*
* Are we prepared to handle this kernel fault?
* We are almost certainly not prepared to handle instruction faults.
*/
if (!is_el1_instruction_abort(esr) && fixup_exception(regs))
return;
/* ... */
}fixup_exception()繼續呼叫search_exception_tables()，其通過查找_extable段，__extable段存盤exception table，每個entry存盤著例外地址及其對應修復的地址，例如上述的 9998:subx0,end,dst指令的地址就會被找到并修改do_page_fault()函式的回傳地址，以達到跳轉修復的功能，其實查找程序是根據出問題的地址addr，查找_extable段（exception table）是否有對應的exception table entry，如果有就代表可以被修復，由于32位處理器和64位處理器實作方式有差別，因此我們先從32位處理器例外表的實作原理說起，
_extable段的首尾地址分別是 __start___ex_table和 __stop___ex_table（定義在include/asm-generic/vmlinux.lds.h，這段記憶體可以看作是一個陣列，陣列的每個元素都是 struct exception_table_entry型別，其記錄著例外發生地址及其對應的修復地址，
exception tables
__start___ex_table --> +---------------+
| entry |
+---------------+
| entry |
+---------------+
| ... |
+---------------+
| entry |
+---------------+
| entry |
__stop___ex_table --> +---------------+在32位處理器上，struct exception_table_entry定義如下：
struct exception_table_entry {
unsigned long insn, fixup;
};有一點需要明確，在32位處理器上，unsigned long是4 bytes，insn和fixup分別存盤例外發生地址及其對應的修復地址，根據例外地址ex_addr查找對應的修復地址（未找到回傳0），其示意代碼如下：
unsigned long search_fixup_addr32(unsigned long ex_addr)
{
const struct exception_table_entry *e;
for (e = __start___ex_table; e < __stop___ex_table; e++)
if (ex_addr == e->insn)
return e->fixup;
return 0;
}在32位處理器上，創建exception table entry相對簡單，針對copy{to,from}user()匯編代碼中每一處用戶空間地址訪問的指令都會創建一個entry，并且insn存盤當前指令對應的地址，fixup存盤修復指令對應的地址，
當64位處理器開始發展起來，如果我們繼續使用這種方式，勢必需要2倍于32位處理器的記憶體存盤exception table（因為存盤一個地址需要8 bytes），所以，kernel換用另一種方式實作，在64處理器上，struct exception_table_entry定義如下：
struct exception_table_entry {
int insn, fixup;
};每個exception table entry占用的記憶體和32位處理器情況一樣，因此記憶體占用不變，但是insn和fixup的意義發生變化，insn和fixup分別存盤著例外發生地址及修復地址相對于當前結構體成員地址的偏移（有點拗口），例如，根據例外地址ex_addr查找對應的修復地址（未找到回傳0），其示意代碼如下：
unsigned long search_fixup_addr64(unsigned long ex_addr)
{
const struct exception_table_entry *e;
for (e = __start___ex_table; e < __stop___ex_table; e++)
if (ex_addr == (unsigned long)&e->insn + e->insn)
return (unsigned long)&e->fixup + e->fixup;
return 0;
}因此，我們的關注點就是如何去構建exception_table_entry，我們針對每個用戶空間地址的記憶體訪問都需要創建一個exception table entry，并插入_extable段，例如下面的匯編指令（匯編指令對應的地址是隨意寫的，不用糾結對錯，理解原理才是王道），
0xffff000000000000: ldr x1, [x0]
0xffff000000000004: add x1, x1, #0x10
0xffff000000000008: ldr x2, [x0, #0x10]
/* ... */
0xffff000040000000: mov x0, #0xfffffffffffffff2 // -14
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，
所以，如果內核態訪問非法用戶空間地址究竟發生了什么？上面的分析流程可以總結如下：
訪問非法用戶空間地址：
0xffff000000000000:ldr x1,[x0]
MMU觸發例外
CPU呼叫do_page_fault()
do_page_fault()呼叫search_exception_table()（regs->pc == 0xffff000000000000）
查看_extable段，尋找0xffff000000000000 并且回傳修復地址0xffff000040000000
do_page_fault()修改函式回傳地址（regs->pc = 0xffff000040000000）并回傳
程式繼續執行，處理出錯情況
修改函式回傳值x0 = -EFAULT (-14) 并回傳（ARM64通過x0傳遞函式回傳值）
總結
到了回顧總結的時候，copy_{to,from}_user()的思考也到此結束，我們來個總結結束此文，
無論是內核態還是用戶態訪問合法的用戶空間地址，當虛擬地址并未建立物理地址的映射關系的時候，page fault的流程幾乎一樣，都會幫助我們申請物理記憶體并創建映射關系，所以這種情況下memcpy()和copy_{to,from}_user()是類似的，
當內核態訪問非法用戶空間地址的時候，根據例外地址查找修復地址，這種修復例外的方法并不是建立地址映射關系，而是修改do_page_fault()回傳地址，而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()，
本文轉載自蝸窩科技:
http://www.wowotech.net/memory_management/454.html
（完）
更多精彩，盡在"Linux閱碼場"，掃描下方二維碼關注
感謝您的耐心閱讀，請隨手轉發一下或者點個“在看”吧~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/224410.html
標籤：其他