一、什么是copy_{to,from}_user()

它是kernel space和user space溝通的橋梁。所有的數(shù)據(jù)交互都應該使用類似這種接口。但是他的作用究竟是什么呢？我們對下提出疑問：

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

溫馨提示：文章代碼分析基于Linux-4.18.0，部分架構(gòu)相關代碼以ARM64為代表。

1、copy_{to,from}_user()對比memcpy()

• copy_{to,from}_user()比memcpy()多了傳入地址合法性校驗。例如是否屬于用戶空間地址范圍。理論上說，內(nèi)核空間可以直接使用用戶空間傳過來的指針，即使要做數(shù)據(jù)拷貝的動作，也可以直接使用memcpy()，事實上在沒有MMU的體系架構(gòu)上，copy_{to,from}_user()最終的實現(xiàn)就是利用了mencpy()。但是對于大多數(shù)有MMU的平臺，情況就有了些變化：用戶空間傳過來的指針是在虛擬地址空間上的，它所指向的虛擬地址空間很可能還沒有真正映射到實際的物理頁面上。但是這又能怎樣呢？缺頁導致的異常會很透明地被內(nèi)核予以修復（為缺頁的地址空間提交新的物理頁面），訪問到缺頁的指令會繼續(xù)運行仿佛什么都沒有發(fā)生一樣。但這只是用戶空間缺頁異常的行為，在內(nèi)核空間這種缺頁異常必須被顯式地修復，這是由內(nèi)核提供的缺頁異常處理函數(shù)的設計模式?jīng)Q定的。其背后的思想是：在內(nèi)核態(tài)，如果程序試圖訪問一個尚未被提交物理頁面的用戶空間地址，內(nèi)核必須對此保持警惕而不能像用戶空間那樣毫無察覺。
• 如果我們確保用戶態(tài)傳遞的指針的正確性，我們完全可以用memcpy()函數(shù)替代copy_{to,from}_user()。經(jīng)過一些試驗測試，發(fā)現(xiàn)使用memcpy()，程序的運行上并沒有問題。因此在確保用戶態(tài)指針安全的情況下，二者可以替換。
  

 從各家博客上，觀點主要集中在第一點?？雌饋淼谝稽c受到大家的廣泛認可。但是，注重實踐的人又得出了第二種觀點，畢竟是實踐出真知。真理究竟是是掌握在少數(shù)人手里呢？還是群眾的眼睛是雪亮的呢？當然，我不否定以上任何一種觀點。也不能向你保證哪種觀點正確。因為，我相信即使是曾經(jīng)無懈可擊的理論，隨著時間的推移或者特定情況的改變理論也可能不再正確。比如，牛頓的經(jīng)典力學理論（好像扯得有點遠）。如果要我說人話，就是：隨著時間的推移，Linux的代碼在不斷的變化?；蛟S以上的觀點在曾經(jīng)正確。當然，也可能現(xiàn)在還正確。下面的分析就是我的觀點了。同樣，大家也是需要保持懷疑的態(tài)度。

2、函數(shù)定義

首先我們看下memcpy()和copy_{to,from}_user()的函數(shù)定義。參數(shù)幾乎沒有差別，都包含目的地址，源地址和需要復制的字節(jié)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數(shù)據(jù)到內(nèi)核空間，用戶空間地址to及to加上copy的字節(jié)長度n必須位于用戶空間地址空間。
• 如果從內(nèi)核空間copy數(shù)據(jù)到用戶空間，當然也需要檢查地址的合法性。例如，是否越界訪問或者是不是代碼段的數(shù)據(jù)等等?？傊磺胁缓戏ǖ夭僮鞫夹枰⒖潭沤^。
  

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

第一種情況的結(jié)果是：使用memcpy()測試，沒有出現(xiàn)問題，代碼正常運行。測試代碼如下（僅僅展示proc文件系統(tǒng)下file_operations對應的read接口函數(shù)）：

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命令讀取文件內(nèi)容，cat會通過系統(tǒng)調(diào)用read調(diào)用test_read，并且傳遞的buf大小是4k。測試很順利，結(jié)果很喜人。成功地讀到了“test”字符串?？雌饋恚?點觀點是沒毛病的。但是，我們還需要繼續(xù)驗證和探究下去。因為第1個觀點提到，“在內(nèi)核空間這種缺頁異常必須被顯式地修復”。因此我們還需要驗證的情況是：如果buf在用戶空間已經(jīng)分配虛擬地址空間，但是并沒有建立和物理內(nèi)存的具體映射關系，這種情況下會出現(xiàn)內(nèi)核態(tài)page fault。我們首先需要創(chuàng)建這種條件，找到符合的buf，然后測試。這里我當然沒測啦。因為有測試結(jié)論（主要是因為我懶，構(gòu)造這個條件我覺得比較麻煩）。這個測試是我的一個朋友，人稱宋老師的“阿助教”阿克曼大牛。他曾經(jīng)做個這個實驗，并且得到的結(jié)論是：即使是沒有建立和物理內(nèi)存的具體映射關系的buf，代碼也可以正常運行。在內(nèi)核態(tài)發(fā)生page fault，并被其修復（分配具體物理內(nèi)存，填充頁表，建立映射關系）。同時，我從代碼的角度分析，結(jié)論也是如此。

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

第二種情況的結(jié)果是：以上的測試代碼并沒有正常運行，并且會觸發(fā)kernel oops。當然本次測試和上次測試的kernel配置選項是不一樣的。這個配置項是 CONFIG_ARM64_SW_TTBR0_PAN或者 CONFIG_ARM64_PAN（針對ARM64平臺）。兩個配置選項的功能都是阻止內(nèi)核態(tài)直接訪問用戶地址空間。只不過CONFIG_ARM64_SW_TTBR0_PAN是軟件仿真實現(xiàn)這種功能，而CONFIG_ARM64_PAN是硬件實現(xiàn)功能（ARMv8.1擴展功能）。我們以CONFIG_ARM64_SW_TTBR0_PAN作為分析對象（軟件仿真才有代碼提供分析）。BTW，如果硬件不支持，即使配置CONFIG_ARM64_PAN也沒用，只能使用軟件仿真的方法。如果需要訪問用戶空間地址需要通過類似copy_{to,from}_user()的接口，否則會導致kernel oops。

在打開CONFIG_ARM64_SW_TTBR0_PAN的選項后，測試以上代碼就會導致kernel oops。原因就是內(nèi)核態(tài)直接訪問了用戶空間地址。因此，在這種情況我們就不可以使用memcpy()。我們別無選擇，只能使用copy_{to,from}_user()。

為什么我們需要PAN（Privileged Access Never）功能呢？原因可能是用戶空間和內(nèi)核空間數(shù)據(jù)交互上容易引入安全問題，所以我們就不讓內(nèi)核空間輕易訪問用戶空間，如果非要這么做，就必須通過特定的接口關閉PAN。另一方面，PAN功能可以更加規(guī)范化內(nèi)核態(tài)和用戶態(tài)數(shù)據(jù)交互的接口使用。在使能PAN功能的情況下，可以迫使內(nèi)核或者驅(qū)動開發(fā)者使用copy_{to,from}_user()等安全接口，提升系統(tǒng)的安全性。類似memcpy()非規(guī)范操作，kernel就oops給你看。

    由于編程的不規(guī)范而引入安全漏洞。例如：Linux內(nèi)核漏洞CVE-2017-5123可以提升權限。該漏洞的引入原因就是是缺少access_ok()檢查用戶傳遞地址的合法性。因此，為了避免自己編寫的代碼引入安全問題，針對內(nèi)核空間和用戶空間數(shù)據(jù)交互上，我們要格外當心。

二、CONFIG_ARM64_SW_TTBR0_PAN原理

 CONFIG_ARM64_SW_TTBR0_PAN原理背后設計的原理。由于ARM64的硬件特殊設計，我們使用兩個頁表基地址寄存器ttbr0_el1和ttbr1_el1。處理器根據(jù)64 bit地址的高16 bit判斷訪問的地址屬于用戶空間還是內(nèi)核空間。如果是用戶空間地址則使用ttbr0_el1，反之使用ttbr1_el1。因此，ARM64進程切換的時候，只需要改變ttbr0_el1的值即可。ttbr1_el1可以選擇不需要改變，因為所有的進程共享相同的內(nèi)核空間地址。

當進程切換到內(nèi)核態(tài)（中斷，異常，系統(tǒng)調(diào)用等）后，如何才能避免內(nèi)核態(tài)訪問用戶態(tài)地址空間呢？其實不難想出，改變ttbr0_el1的值即可，指向一段非法的映射即可。因此，我們?yōu)榇藴蕚淞艘环萏厥獾捻摫恚擁摫泶笮?k內(nèi)存，其值全是0。當進程切換到內(nèi)核態(tài)后，修改ttbr0_el1的值為該頁表的地址即可保證訪問用戶空間地址是非法訪問。因為頁表的值是非法的。這個特殊的頁表內(nèi)存通過鏈接腳本分配。

#define RESERVED_TTBR0_SIZE    (PAGE_SIZE) 
SECTIONS 
{ 
        reserved_ttbr0 = .; 
        . += RESERVED_TTBR0_SIZE; 
        swapper_pg_dir = .; 
        . += SWAPPER_DIR_SIZE; 
        swapper_pg_end = .; 
}

這個特殊的頁表和內(nèi)核頁表在一起。和swapper_pg_dir僅僅差4k大小。reserved_ttbr0地址開始的4k內(nèi)存空間的內(nèi)容會被清零。

當我們進入內(nèi)核態(tài)后會通過__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存儲的是內(nèi)核頁表基地址，因此其值就是swapper_pg_dir。
• swapper_pg_dir減去RESERVED_TTBR0_SIZE就是上面描述的特殊頁表。
• 將ttbr0_el1修改指向這個特殊的頁表基地址，當然可以保證后續(xù)訪問用戶地址都是非法的。

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

現(xiàn)在我們可以解答上一節(jié)中遺留的問題。怎樣才能繼續(xù)使用memcpy()？現(xiàn)在就很簡單了，在memcpy()調(diào)用之前通過uaccess_enable_not_uao()允許內(nèi)核態(tài)訪問用戶空間地址，調(diào)用memcpy()，最后通過uaccess_disable_not_uao()關閉內(nèi)核態(tài)訪問用戶空間的能力。

三、測試

以上的測試用例都是建立在用戶空間傳遞合法地址的基礎上測試的，何為合法的用戶空間地址？用戶空間通過系統(tǒng)調(diào)用申請的虛擬地址空間包含的地址范圍，即是合法的地址（不論是否分配物理頁面建立映射關系）。既然要寫一個接口程序，當然也要考慮程序的健壯性，我們不能假設所有的用戶傳遞的參數(shù)都是合法的。我們應該預判非法傳參情況的發(fā)生，并提前做好準備，這就是未雨綢繆。

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

我們以copy_to_user()為例分析。函數(shù)調(diào)用流程是：

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

_arch_copy_to_user()在ARM64平臺是匯編代碼實現(xiàn)，這部分代碼很關鍵。

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是上面說到的內(nèi)核態(tài)訪問用戶空間的開關。
• copy_template.S文件是匯編實現(xiàn)的memcpy()的功能，稍后看看memcpy()的實現(xiàn)代碼就清楚了。
• .section.fixup,“ax”定義一個section，名為“.fixup”，權限是ax（‘a(chǎn)'可重定位的段，‘x'可執(zhí)行段）。 9998標號處的指令就是善后處理工作。還記得copy_{to,from}_user()返回值的意義嗎？返回0代表copy成功，否則返回剩余沒有copy的字節(jié)數(shù)。這行代碼就是計算剩余沒有copy的字節(jié)數(shù)。當我們訪問非法的用戶空間地址的時候，就一定會觸發(fā)page fault。這種情況下，內(nèi)核態(tài)發(fā)生的page fault并返回的時候并沒有修復異常，所以肯定不能返回發(fā)生異常的地址繼續(xù)運行。所以，系統(tǒng)可以有2個選擇：第1個選擇是kernel oops，并給當前進程發(fā)送SIGSEGV信號；第2個選擇是不返回出現(xiàn)異常的地址運行，而是選擇一個已經(jīng)修復的地址返回。如果使用的是memcpy()就只有第1個選擇。但是copy_{to,from}_user()可以有第2個選擇。 .fixup段就是為了實現(xiàn)這個修復功能。當copy過程中出現(xiàn)訪問非法用戶空間地址的時候，do_page_fault()返回的地址變成 9998標號處，此時可以計算剩余未copy的字節(jié)長度，程序還可以繼續(xù)執(zhí)行。

對比前面分析的結(jié)果，其實_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平臺是由匯編代碼實現(xiàn)。其定義在arch/arm64/lib/memcpy.S文件。

.weak memcpy 
ENTRY(__memcpy) 
ENTRY(memcpy) 
#include "copy_template.S" 
        ret 
ENDPIPROC(memcpy) 
ENDPROC(__memcpy)

所以很明顯，memcpy()和__memcpy()函數(shù)定義是一樣的。并且memcpy()函數(shù)聲明是weak，因此可以重寫memcpy()函數(shù)（扯得有點遠）。再扯一點，為何使用匯編呢？為何不使用lib/string.c文件的memcpy()函數(shù)呢？當然是為了優(yōu)化memcpy() 的執(zhí)行速度。lib/string.c文件的memcpy()函數(shù)是按照字節(jié)為單位進行copy（再好的硬件也會被粗糙的代碼毀掉）。但是現(xiàn)在的處理器基本都是32或者64位，完全可以4 bytes或者8 bytes甚至16 bytes copy（考慮地址對齊的情況下）?？梢悦黠@提升執(zhí)行速度。所以，ARM64平臺使用匯編實現(xiàn)。這部分知識可以參考這篇博客《ARM64 的 memcpy 優(yōu)化與實現(xiàn)》。

下面繼續(xù)進入正題，再重復一遍：內(nèi)核態(tài)訪問用戶空間地址，如果觸發(fā)page fault，只要用戶空間地址合法，內(nèi)核態(tài)也會像什么也沒有發(fā)生一樣修復異常（分配物理內(nèi)存，建立頁表映射關系）。但是如果訪問非法用戶空間地址，就選擇第2條路，嘗試救贖自己。這條路就是利用 .fixup和 __ex_table段。如果無力回天只能給當前進程發(fā)送SIGSEGV信號。并且，輕則kernel oops，重則panic（取決于kernel配置選項CONFIG_PANIC_ON_OOPS）。在內(nèi)核態(tài)訪問非法用戶空間地址的情況下，do_page_fault()最終會跳轉(zhuǎn) 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()繼續(xù)調(diào)用search_exception_tables()，其通過查找_extable段。__extable段存儲exception table，每個entry存儲著異常地址及其對應修復的地址。例如上述的 9998:subx0,end,dst指令的地址就會被找到并修改do_page_fault()函數(shù)的返回地址，以達到跳轉(zhuǎn)修復的功能。其實查找過程是根據(jù)出問題的地址addr，查找_extable段（exception table）是否有對應的exception table entry，如果有就代表可以被修復。由于32位處理器和64位處理器實現(xiàn)方式有差別，因此我們先從32位處理器異常表的實現(xiàn)原理說起。

_extable段的首尾地址分別是 __start___ex_table和 __stop___ex_table（定義在include/asm-generic/vmlinux.lds.h。這段內(nèi)存可以看作是一個數(shù)組，數(shù)組的每個元素都是 struct exception_table_entry類型，其記錄著異常發(fā)生地址及其對應的修復地址。

                        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分別存儲異常發(fā)生地址及其對應的修復地址。根據(jù)異常地址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位處理器上，創(chuàng)建exception table entry相對簡單。針對copy{to,from}user()匯編代碼中每一處用戶空間地址訪問的指令都會創(chuàng)建一個entry，并且insn存儲當前指令對應的地址，fixup存儲修復指令對應的地址。

當64位處理器開始發(fā)展起來，如果我們繼續(xù)使用這種方式，勢必需要2倍于32位處理器的內(nèi)存存儲exception table（因為存儲一個地址需要8 bytes）。所以，kernel換用另一種方式實現(xiàn)。在64處理器上，struct exception_table_entry定義如下：

struct exception_table_entry { 
        int insn, fixup; 
};

每個exception table entry占用的內(nèi)存和32位處理器情況一樣，因此內(nèi)存占用不變。但是insn和fixup的意義發(fā)生變化。insn和fixup分別存儲著異常發(fā)生地址及修復地址相對于當前結(jié)構(gòu)體成員地址的偏移（有點拗口）。例如，根據(jù)異常地址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; 
}

因此，我們的關注點就是如何去構(gòu)建exception_table_entry。我們針對每個用戶空間地址的內(nèi)存訪問都需要創(chuàng)建一個exception table entry，并插入_extable段。例如下面的匯編指令（匯編指令對應的地址是隨意寫的，不用糾結(jié)對錯。理解原理才是王道）。

0xffff000000000000: ldr x1, [x0] 
0xffff000000000004: add x1, x1, #0x10 
0xffff000000000008: ldr x2, [x0, #0x10] 
/* ... */ 
0xffff000040000000: mov x0, #0xfffffffffffffff2    // -14 
0xffff000040000004: ret

假設x0寄存器保存著用戶空間地址，因此我們需要對0xffff000000000000地址的匯編指令創(chuàng)建一個exception table entry，并且我們期望當x0是非法用戶空間地址時，跳轉(zhuǎn)返回的修復地址是0xffff000040000000。為了計算簡單，假設這是創(chuàng)建第一個entry， __start___ex_table值是0xffff000080000000。那么第一個exception table entry的insn和fixup成員的值分別是：0x80000000和0xbffffffc（這兩個值都是負數(shù)）。因此，針對copy{to,from}user()匯編代碼中每一處用戶空間地址訪問的指令都會創(chuàng)建一個entry。所以0xffff000000000008地址處的匯編指令也需要創(chuàng)建一個exception table entry。

所以，如果內(nèi)核態(tài)訪問非法用戶空間地址究竟發(fā)生了什么？上面的分析流程可以總結(jié)如下：

• 0xffff000000000000:ldr x1,[x0]
• MMU觸發(fā)異常
• CPU調(diào)用do_page_fault()
• do_page_fault()調(diào)用search_exception_table()（regs->pc == 0xffff000000000000）
• 查看_extable段，尋找0xffff000000000000 并且返回修復地址0xffff000040000000
• do_page_fault()修改函數(shù)返回地址（regs->pc = 0xffff000040000000）并返回
• 程序繼續(xù)執(zhí)行，處理出錯情況
• 修改函數(shù)返回值x0 = -EFAULT (-14) 并返回（ARM64通過x0傳遞函數(shù)返回值）
  

四、總結(jié)

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

無論是內(nèi)核態(tài)還是用戶態(tài)訪問合法的用戶空間地址，當虛擬地址并未建立物理地址的映射關系的時候，page fault的流程幾乎一樣，都會幫助我們申請物理內(nèi)存并創(chuàng)建映射關系。所以這種情況下memcpy()和copy_{to,from}_user()是類似的。

當內(nèi)核態(tài)訪問非法用戶空間地址的時候，根據(jù)異常地址查找修復地址。這種修復異常的方法并不是建立地址映射關系，而是修改do_page_fault()返回地址。而memcpy()無法做到這點。

在使能 CONFIG_ARM64_SW_TTBR0_PAN或者 CONFIG_ARM64_PAN（硬件支持的情況下才有效）的時候，我們只能使用copy_{to,from}_user()這種接口，直接使用memcpy()是不行的。

最后，我想說，即使在某些情況下memcpy()可以正常工作。但是，這也是不推薦的，不是良好的編程習慣。在用戶空間和內(nèi)核空間數(shù)據(jù)交互上，我們必須使用類似copy_{to,from}_user()的接口。為什么類似呢？因為還有其他的接口用于內(nèi)核空間和用戶空間數(shù)據(jù)交互，只是沒有copy_{to,from}_user()出名。例如：{get,put}_user()。

到此這篇關于copy_{to, from}_user()的思考的文章就介紹到這了,更多相關copy、user內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！