天天看點
傳回

copy_{to, from}_user()的思考與伺服器運用define RESERVED_TTBR0_SIZE (PAGE_SIZE)include "copy_template.S"include "copy_template.S"

引言

我們對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);

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)

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定義如下：

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()。（

存儲 安全 Linux linux核心存儲 linux對象存儲 伺服器user 伺服器from Linux系統存儲
上一篇: 帶你讀《Python資料分析與資料化營運（第2版）》之一：Python和資料化營運第1章 Python和資料化營運
下一篇: 大家都關注的Serverless，阿裡怎麼做的？背景現狀收益思考遷移總結

繼續閱讀