這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)Linux中的copy_{to, from}_user函數(shù)介紹，以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
網(wǎng)站建設(shè)公司,為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì)及定制網(wǎng)站建設(shè)服務(wù),專(zhuān)注于成都企業(yè)網(wǎng)站定制,高端網(wǎng)頁(yè)制作,對(duì)成都高空作業(yè)車(chē)租賃等多個(gè)行業(yè)擁有豐富的網(wǎng)站建設(shè)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。專(zhuān)業(yè)網(wǎng)站設(shè)計(jì),網(wǎng)站優(yōu)化推廣哪家好,專(zhuān)業(yè)成都網(wǎng)站營(yíng)銷(xiāo)優(yōu)化,H5建站,響應(yīng)式網(wǎng)站。
我們對(duì)copy_{to,from}_user()接口的使用應(yīng)該是再熟悉不過(guò)吧?；綥inux書(shū)籍都會(huì)介紹它的作用。畢竟它是kernel space和user space溝通的橋梁。所有的數(shù)據(jù)交互都應(yīng)該使用類(lèi)似這種接口。所以，我們沒(méi)有理由不知道接口的作用。但是，我也曾經(jīng)有過(guò)以下疑問(wèn)。
為什么需要copy_{to,from}_user()，它究竟在背后為我們做了什么？
copy_{to,from}_user()和memcpy()的區(qū)別是什么，直接使用memcpy()可以嗎？
memcpy()替代copy_{to,from}_user()是不是一定會(huì)有問(wèn)題？
一下子找回了當(dāng)年困惑的自己。我所提出的每個(gè)問(wèn)題，曾經(jīng)我也思考過(guò)。還不止一次的思考，每一次都有不同的想法。當(dāng)然是因?yàn)閺囊婚_(kāi)始就我就沒(méi)有完全理解?，F(xiàn)在又重新回到這個(gè)沉重的話題，繼續(xù)思考這曾經(jīng)的問(wèn)題。
針對(duì)以上問(wèn)題當(dāng)然是先百度。百度對(duì)于該問(wèn)題的博客也是很多，足以看出這個(gè)問(wèn)題肯定困惑著一大批Linux的愛(ài)好者。對(duì)于我的查閱結(jié)果來(lái)說(shuō)，觀點(diǎn)主要分成以下兩種：
1、copy_{to,from}_user()比memcpy()多了傳入地址合法性校驗(yàn)。
例如是否屬于用戶空間地址范圍。理論上說(shuō)，內(nèi)核空間可以直接使用用戶空間傳過(guò)來(lái)的指針，即使要做數(shù)據(jù)拷貝的動(dòng)作，也可以直接使用memcpy()，事實(shí)上在沒(méi)有MMU的體系架構(gòu)上，copy_{to,from}_user()最終的實(shí)現(xiàn)就是利用了mencpy()。
但是對(duì)于大多數(shù)有MMU的平臺(tái)，情況就有了些變化：用戶空間傳過(guò)來(lái)的指針是在虛擬地址空間上的，它所指向的虛擬地址空間很可能還沒(méi)有真正映射到實(shí)際的物理頁(yè)面上。但是這又能怎樣呢？缺頁(yè)導(dǎo)致的異常會(huì)很透明地被內(nèi)核予以修復(fù)（為缺頁(yè)的地址空間提交新的物理頁(yè)面），訪問(wèn)到缺頁(yè)的指令會(huì)繼續(xù)運(yùn)行仿佛什么都沒(méi)有發(fā)生一樣。但這只是用戶空間缺頁(yè)異常的行為，在內(nèi)核空間這種缺頁(yè)異常必須被顯式地修復(fù)，這是由內(nèi)核提供的缺頁(yè)異常處理函數(shù)的設(shè)計(jì)模式?jīng)Q定的。
其背后的思想是：在內(nèi)核態(tài)，如果程序試圖訪問(wèn)一個(gè)尚未被提交物理頁(yè)面的用戶空間地址，內(nèi)核必須對(duì)此保持警惕而不能像用戶空間那樣毫無(wú)察覺(jué)。
2、如果我們確保用戶態(tài)傳遞的指針的正確性，我們完全可以用memcpy()函數(shù)替代copy_{to,from}_user()。經(jīng)過(guò)一些試驗(yàn)測(cè)試，發(fā)現(xiàn)使用memcpy()，程序的運(yùn)行上并沒(méi)有問(wèn)題。因此在確保用戶態(tài)指針安全的情況下，二者可以替換。
從各家博客上，觀點(diǎn)主要集中在第一點(diǎn)?？雌饋?lái)第一點(diǎn)受到大家的廣泛認(rèn)可。但是，注重實(shí)踐的人又得出了第二種觀點(diǎn)，畢竟是實(shí)踐出真知。真理究竟是是掌握在少數(shù)人手里呢？還是群眾的眼睛是雪亮的呢？當(dāng)然，我不否定以上任何一種觀點(diǎn)。也不能向你保證哪種觀點(diǎn)正確。因?yàn)椋蚁嘈偶词故窃?jīng)無(wú)懈可擊的理論，隨著時(shí)間的推移或者特定情況的改變理論也可能不再正確。比如，牛頓的經(jīng)典力學(xué)理論（好像扯得有點(diǎn)遠(yuǎn)）。如果要我說(shuō)人話，就是：隨著時(shí)間的推移，Linux的代碼在不斷的變化?；蛟S以上的觀點(diǎn)在曾經(jīng)正確。當(dāng)然，也可能現(xiàn)在還正確。下面的分析就是我的觀點(diǎn)了。同樣，大家也是需要保持懷疑的態(tài)度。下面我就拋磚引玉。
首先我們看下memcpy()和copy_{to,from}_user()的函數(shù)定義。參數(shù)幾乎沒(méi)有差別，都包含目的地址，源地址和需要復(fù)制的字節(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);
但是，有一點(diǎn)我們肯定是知道的。那就是memcpy()沒(méi)有傳入地址合法性校驗(yàn)。而copy_{to,from}_user()針對(duì)傳入地址進(jìn)行類(lèi)似下面的合法性校驗(yàn)（簡(jiǎn)單說(shuō)點(diǎn)，更多校驗(yàn)詳情可以參考代碼）。
如果從用戶空間copy數(shù)據(jù)到內(nèi)核空間，用戶空間地址to及to加上copy的字節(jié)長(zhǎng)度n必須位于用戶空間地址空間。
如果從內(nèi)核空間copy數(shù)據(jù)到用戶空間，當(dāng)然也需要檢查地址的合法性。例如，是否越界訪問(wèn)或者是不是代碼段的數(shù)據(jù)等等。總之一切不合法地操作都需要立刻杜絕。
經(jīng)過(guò)簡(jiǎn)單的對(duì)比之后，我們?cè)倏纯雌渌牟町愐约耙黄鹛接懴律厦嫣岢龅?個(gè)觀點(diǎn)。我們先從第2個(gè)觀點(diǎn)說(shuō)起。涉及實(shí)踐，我還是有點(diǎn)相信實(shí)踐出真知。從我測(cè)試的結(jié)果來(lái)說(shuō)，實(shí)現(xiàn)結(jié)果分成兩種情況。
第一種情況的結(jié)果是：使用memcpy()測(cè)試，沒(méi)有出現(xiàn)問(wèn)題，代碼正常運(yùn)行。測(cè)試代碼如下（僅僅展示proc文件系統(tǒng)下file_operations對(duì)應(yīng)的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會(huì)通過(guò)系統(tǒng)調(diào)用read調(diào)用test_read，并且傳遞的buf大小是4k。
測(cè)試很順利，結(jié)果很喜人。成功地讀到了“test”字符串。看起來(lái)，第2點(diǎn)觀點(diǎn)是沒(méi)毛病的。但是，我們還需要繼續(xù)驗(yàn)證和探究下去。因?yàn)榈?個(gè)觀點(diǎn)提到，“在內(nèi)核空間這種缺頁(yè)異常必須被顯式地修復(fù)”。
因此我們還需要驗(yàn)證的情況是：如果buf在用戶空間已經(jīng)分配虛擬地址空間，但是并沒(méi)有建立和物理內(nèi)存的具體映射關(guān)系，這種情況下會(huì)出現(xiàn)內(nèi)核態(tài)page fault。我們首先需要?jiǎng)?chuàng)建這種條件，找到符合的buf，然后測(cè)試。這里我當(dāng)然沒(méi)測(cè)啦。因?yàn)橛袦y(cè)試結(jié)論（主要是因?yàn)槲覒?，?gòu)造這個(gè)條件我覺(jué)得比較麻煩）。
這個(gè)測(cè)試是我的一個(gè)朋友，人稱(chēng)宋老師的“阿助教”阿克曼大牛。他曾經(jīng)做個(gè)這個(gè)實(shí)驗(yàn)，并且得到的結(jié)論是：即使是沒(méi)有建立和物理內(nèi)存的具體映射關(guān)系的buf，代碼也可以正常運(yùn)行。在內(nèi)核態(tài)發(fā)生page fault，并被其修復(fù)（分配具體物理內(nèi)存，填充頁(yè)表，建立映射關(guān)系）。同時(shí)，我從代碼的角度分析，結(jié)論也是如此。
經(jīng)過(guò)上面的分析，看起來(lái)好像是memcpy()也可以正常使用，鑒于安全地考慮建議使用copy_{to,from}_user()等接口。
第二種情況的結(jié)果是：以上的測(cè)試代碼并沒(méi)有正常運(yùn)行，并且會(huì)觸發(fā)kernel oops。當(dāng)然本次測(cè)試和上次測(cè)試的kernel配置選項(xiàng)是不一樣的。這個(gè)配置項(xiàng)是 CONFIG_ARM64_SW_TTBR0_PAN或者 CONFIG_ARM64_PAN（針對(duì)ARM64平臺(tái)）。兩個(gè)配置選項(xiàng)的功能都是阻止內(nèi)核態(tài)直接訪問(wèn)用戶地址空間。只不過(guò)CONFIG_ARM64_SW_TTBR0_PAN是軟件仿真實(shí)現(xiàn)這種功能，而CONFIG_ARM64_PAN是硬件實(shí)現(xiàn)功能（ARMv8.1擴(kuò)展功能）。我們以CONFIG_ARM64_SW_TTBR0_PAN作為分析對(duì)象（軟件仿真才有代碼提供分析）。BTW，如果硬件不支持，即使配置CONFIG_ARM64_PAN也沒(méi)用，只能使用軟件仿真的方法。如果需要訪問(wèn)用戶空間地址需要通過(guò)類(lèi)似copy_{to,from}_user()的接口，否則會(huì)導(dǎo)致kernel oops。
在打開(kāi)CONFIG_ARM64_SW_TTBR0_PAN的選項(xiàng)后，測(cè)試以上代碼就會(huì)導(dǎo)致kernel oops。原因就是內(nèi)核態(tài)直接訪問(wèn)了用戶空間地址。因此，在這種情況我們就不可以使用memcpy()。我們別無(wú)選擇，只能使用copy_{to,from}_user()。
為什么我們需要PAN（Privileged Access Never）功能呢？原因可能是用戶空間和內(nèi)核空間數(shù)據(jù)交互上容易引入安全問(wèn)題，所以我們就不讓內(nèi)核空間輕易訪問(wèn)用戶空間，如果非要這么做，就必須通過(guò)特定的接口關(guān)閉PAN。另一方面，PAN功能可以更加規(guī)范化內(nèi)核態(tài)和用戶態(tài)數(shù)據(jù)交互的接口使用。在使能PAN功能的情況下，可以迫使內(nèi)核或者驅(qū)動(dòng)開(kāi)發(fā)者使用copy_{to,from}_user()等安全接口，提升系統(tǒng)的安全性。類(lèi)似memcpy()非規(guī)范操作，kernel就oops給你看。
由于編程的不規(guī)范而引入安全漏洞。例如：Linux內(nèi)核漏洞CVE-2017-5123可以提升權(quán)限。該漏洞的引入原因就是是缺少access_ok()檢查用戶傳遞地址的合法性。因此，為了避免自己編寫(xiě)的代碼引入安全問(wèn)題，針對(duì)內(nèi)核空間和用戶空間數(shù)據(jù)交互上，我們要格外當(dāng)心。
既然提到了CONFIG_ARM64_SW_TTBR0_PAN的配置選項(xiàng)。當(dāng)然我也希望了解其背后設(shè)計(jì)的原理。由于ARM64的硬件特殊設(shè)計(jì)，我們使用兩個(gè)頁(yè)表基地址寄存器ttbr0_el1和ttbr1_el1。處理器根據(jù)64 bit地址的高16 bit判斷訪問(wèn)的地址屬于用戶空間還是內(nèi)核空間。如果是用戶空間地址則使用ttbr0_el1，反之使用ttbr1_el1。因此，ARM64進(jìn)程切換的時(shí)候，只需要改變ttbr0_el1的值即可。ttbr1_el1可以選擇不需要改變，因?yàn)樗械倪M(jìn)程共享相同的內(nèi)核空間地址。
當(dāng)進(jìn)程切換到內(nèi)核態(tài)（中斷，異常，系統(tǒng)調(diào)用等）后，如何才能避免內(nèi)核態(tài)訪問(wèn)用戶態(tài)地址空間呢？其實(shí)不難想出，改變ttbr0_el1的值即可，指向一段非法的映射即可。因此，我們?yōu)榇藴?zhǔn)備了一份特殊的頁(yè)表，該頁(yè)表大小4k內(nèi)存，其值全是0。當(dāng)進(jìn)程切換到內(nèi)核態(tài)后，修改ttbr0_el1的值為該頁(yè)表的地址即可保證訪問(wèn)用戶空間地址是非法訪問(wèn)。因?yàn)轫?yè)表的值是非法的。這個(gè)特殊的頁(yè)表內(nèi)存通過(guò)鏈接腳本分配。
#define RESERVED_TTBR0_SIZE (PAGE_SIZE)
SECTIONS
{
reserved_ttbr0 = .;
. += RESERVED_TTBR0_SIZE;
swapper_pg_dir = .;
. += SWAPPER_DIR_SIZE;
swapper_pg_end = .;
}這個(gè)特殊的頁(yè)表和內(nèi)核頁(yè)表在一起。和swapper_pg_dir僅僅差4k大小。reserved_ttbr0地址開(kāi)始的4k內(nèi)存空間的內(nèi)容會(huì)被清零。
當(dāng)我們進(jìn)入內(nèi)核態(tài)后會(huì)通過(guò)__uaccess_ttbr0_disable切換ttbr0_el1以關(guān)閉用戶空間地址訪問(wèn)，在需要訪問(wèn)的時(shí)候通過(guò)_uaccess_ttbr0_enable打開(kāi)用戶空間地址訪問(wèn)。這兩個(gè)宏定義也不復(fù)雜，就以_uaccess_ttbr0_disable為例說(shuō)明原理。其定義如下：
.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存儲(chǔ)的是內(nèi)核頁(yè)表基地址，因此其值就是swapper_pg_dir。
swapper_pg_dir減去RESERVED_TTBR0_SIZE就是上面描述的特殊頁(yè)表。
將ttbr0_el1修改指向這個(gè)特殊的頁(yè)表基地址，當(dāng)然可以保證后續(xù)訪問(wèn)用戶地址都是非法的。
__uaccess_ttbr0_disable對(duì)應(yīng)的C語(yǔ)言實(shí)現(xiàn)可以參考這里。
如何允許內(nèi)核態(tài)訪問(wèn)用戶空間地址呢？也很簡(jiǎn)單，就是__uaccess_ttbr0_disable的反操作，給ttbr0_el1賦予合法的頁(yè)表基地址。這里就不必重復(fù)了。
我們現(xiàn)在需要知道的事實(shí)就是，在配置CONFIG_ARM64_SW_TTBR0_PAN的情況下，copy_{to,from}_user()接口會(huì)在copy之前允許內(nèi)核態(tài)訪問(wèn)用戶空間，并在copy結(jié)束之后關(guān)閉內(nèi)核態(tài)訪問(wèn)用戶空間的能力。因此，使用copy_{to,from}_user()才是正統(tǒng)做法。主要體現(xiàn)在安全性檢查及安全訪問(wèn)處理。這里是其比memcpy()多的第一個(gè)特性，后面還會(huì)介紹另一個(gè)重要特性。
現(xiàn)在我們可以解答上一節(jié)中遺留的問(wèn)題。怎樣才能繼續(xù)使用memcpy()？現(xiàn)在就很簡(jiǎn)單了，在memcpy()調(diào)用之前通過(guò)uaccess_enable_not_uao()允許內(nèi)核態(tài)訪問(wèn)用戶空間地址，調(diào)用memcpy()，最后通過(guò)uaccess_disable_not_uao()關(guān)閉內(nèi)核態(tài)訪問(wèn)用戶空間的能力。
以上的測(cè)試用例都是建立在用戶空間傳遞合法地址的基礎(chǔ)上測(cè)試的，何為合法的用戶空間地址？
用戶空間通過(guò)系統(tǒng)調(diào)用申請(qǐng)的虛擬地址空間包含的地址范圍，即是合法的地址（不論是否分配物理頁(yè)面建立映射關(guān)系）。既然要寫(xiě)一個(gè)接口程序，當(dāng)然也要考慮程序的健壯性，我們不能假設(shè)所有的用戶傳遞的參數(shù)都是合法的。我們應(yīng)該預(yù)判非法傳參情況的發(fā)生，并提前做好準(zhǔn)備，這就是未雨綢繆。
我們首先使用memcpy()的測(cè)試用例，隨機(jī)傳遞一個(gè)非法的地址。經(jīng)過(guò)測(cè)試發(fā)現(xiàn)：會(huì)觸發(fā)kernel oops。繼續(xù)使用copy_{to,from}_user()替代memcpy()測(cè)試。
測(cè)試發(fā)現(xiàn)：read()僅僅是返回錯(cuò)誤，但不會(huì)觸發(fā)kernel oops。這才是我們想要的結(jié)果。畢竟，一個(gè)應(yīng)用程序不應(yīng)該觸發(fā)kernel oops。這種機(jī)制的實(shí)現(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平臺(tái)是匯編代碼實(shí)現(xiàn)，這部分代碼很關(guā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是上面說(shuō)到的內(nèi)核態(tài)訪問(wèn)用戶空間的開(kāi)關(guān)。
copy_template.S文件是匯編實(shí)現(xiàn)的memcpy()的功能，稍后看看memcpy()的實(shí)現(xiàn)代碼就清楚了。
.section.fixup,“ax”定義一個(gè)section，名為“.fixup”，權(quán)限是ax（‘a(chǎn)’可重定位的段，‘x’可執(zhí)行段）。9998標(biāo)號(hào)處的指令就是“未雨綢繆”的善后處理工作。還記得copy_{to,from}_user()返回值的意義嗎？返回0代表copy成功，否則返回剩余沒(méi)有copy的字節(jié)數(shù)。這行代碼就是計(jì)算剩余沒(méi)有copy的字節(jié)數(shù)。當(dāng)我們?cè)L問(wèn)非法的用戶空間地址的時(shí)候，就一定會(huì)觸發(fā)page fault。這種情況下，內(nèi)核態(tài)發(fā)生的page fault并返回的時(shí)候并沒(méi)有修復(fù)異常，所以肯定不能返回發(fā)生異常的地址繼續(xù)運(yùn)行。所以，系統(tǒng)可以有2個(gè)選擇：第1個(gè)選擇是kernel oops，并給當(dāng)前進(jìn)程發(fā)送SIGSEGV信號(hào)；第2個(gè)選擇是不返回出現(xiàn)異常的地址運(yùn)行，而是選擇一個(gè)已經(jīng)修復(fù)的地址返回。如果使用的是memcpy()就只有第1個(gè)選擇。但是copy_{to,from}_user()可以有第2個(gè)選擇。.fixup段就是為了實(shí)現(xiàn)這個(gè)修復(fù)功能。當(dāng)copy過(guò)程中出現(xiàn)訪問(wèn)非法用戶空間地址的時(shí)候，do_page_fault()返回的地址變成9998標(biāo)號(hào)處，此時(shí)可以計(jì)算剩余未copy的字節(jié)長(zhǎng)度，程序還可以繼續(xù)執(zhí)行。
對(duì)比前面分析的結(jié)果，其實(shí)_arch_copy_to_user()可以近似等效如下關(guān)系。
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平臺(tái)是由匯編代碼實(shí)現(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，因此可以重寫(xiě)memcpy()函數(shù)（扯得有點(diǎn)遠(yuǎn)）。再扯一點(diǎn)，為何使用匯編呢？為何不使用lib/string.c文件的memcpy()函數(shù)呢？當(dāng)然是為了優(yōu)化memcpy() 的執(zhí)行速度。lib/string.c文件的memcpy()函數(shù)是按照字節(jié)為單位進(jìn)行copy（再好的硬件也會(huì)被粗糙的代碼毀掉）。
但是現(xiàn)在的處理器基本都是32或者64位，完全可以4 bytes或者8 bytes甚至16 bytes copy（考慮地址對(duì)齊的情況下）。可以明顯提升執(zhí)行速度。所以，ARM64平臺(tái)使用匯編實(shí)現(xiàn)。這部分知識(shí)可以參考這篇博客《ARM64 的 memcpy 優(yōu)化與實(shí)現(xiàn)》。
下面繼續(xù)進(jìn)入正題，再重復(fù)一遍：內(nèi)核態(tài)訪問(wèn)用戶空間地址，如果觸發(fā)page fault，只要用戶空間地址合法，內(nèi)核態(tài)也會(huì)像什么也沒(méi)有發(fā)生一樣修復(fù)異常（分配物理內(nèi)存，建立頁(yè)表映射關(guān)系）。但是如果訪問(wèn)非法用戶空間地址，就選擇第2條路，嘗試救贖自己。這條路就是利用 .fixup和 __ex_table段。
如果無(wú)力回天只能給當(dāng)前進(jìn)程發(fā)送SIGSEGV信號(hào)。并且，輕則kernel oops，重則panic（取決于kernel配置選項(xiàng)CONFIG_PANIC_ON_OOPS）。在內(nèi)核態(tài)訪問(wèn)非法用戶空間地址的情況下，do_page_fault()最終會(huì)跳轉(zhuǎn) no_context標(biāo)號(hào)處的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()，其通過(guò)查找_extable段。__extable段存儲(chǔ)exception table，每個(gè)entry存儲(chǔ)著異常地址及其對(duì)應(yīng)修復(fù)的地址。
例如上述的 9998:subx0,end,dst指令的地址就會(huì)被找到并修改do_page_fault()函數(shù)的返回地址，以達(dá)到跳轉(zhuǎn)修復(fù)的功能。其實(shí)查找過(guò)程是根據(jù)出問(wèn)題的地址addr，查找_extable段（exception table）是否有對(duì)應(yīng)的exception table entry，如果有就代表可以被修復(fù)。由于32位處理器和64位處理器實(shí)現(xiàn)方式有差別，因此我們先從32位處理器異常表的實(shí)現(xiàn)原理說(shuō)起。
_extable段的首尾地址分別是 __start___ex_table和 __stop___ex_table（定義在include/asm-generic/vmlinux.lds.h。這段內(nèi)存可以看作是一個(gè)數(shù)組，數(shù)組的每個(gè)元素都是 struct exception_table_entry類(lèi)型，其記錄著異常發(fā)生地址及其對(duì)應(yīng)的修復(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;
};有一點(diǎn)需要明確，在32位處理器上，unsigned long是4 bytes。insn和fixup分別存儲(chǔ)異常發(fā)生地址及其對(duì)應(yīng)的修復(fù)地址。根據(jù)異常地址ex_addr查找對(duì)應(yīng)的修復(fù)地址（未找到返回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相對(duì)簡(jiǎn)單。針對(duì)copy{to,from}user()匯編代碼中每一處用戶空間地址訪問(wèn)的指令都會(huì)創(chuàng)建一個(gè)entry，并且insn存儲(chǔ)當(dāng)前指令對(duì)應(yīng)的地址，fixup存儲(chǔ)修復(fù)指令對(duì)應(yīng)的地址。
當(dāng)64位處理器開(kāi)始發(fā)展起來(lái)，如果我們繼續(xù)使用這種方式，勢(shì)必需要2倍于32位處理器的內(nèi)存存儲(chǔ)exception table（因?yàn)榇鎯?chǔ)一個(gè)地址需要8 bytes）。所以，kernel換用另一種方式實(shí)現(xiàn)。在64處理器上，struct exception_table_entry定義如下：
struct exception_table_entry {
int insn, fixup;
};每個(gè)exception table entry占用的內(nèi)存和32位處理器情況一樣，因此內(nèi)存占用不變。但是insn和fixup的意義發(fā)生變化。insn和fixup分別存儲(chǔ)著異常發(fā)生地址及修復(fù)地址相對(duì)于當(dāng)前結(jié)構(gòu)體成員地址的偏移（有點(diǎn)拗口）。例如，根據(jù)異常地址ex_addr查找對(duì)應(yīng)的修復(fù)地址（未找到返回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;
}因此，我們的關(guān)注點(diǎn)就是如何去構(gòu)建exception_table_entry。我們針對(duì)每個(gè)用戶空間地址的內(nèi)存訪問(wèn)都需要?jiǎng)?chuàng)建一個(gè)exception table entry，并插入_extable段。例如下面的匯編指令（匯編指令對(duì)應(yīng)的地址是隨意寫(xiě)的，不用糾結(jié)對(duì)錯(cuò)。理解原理才是王道）。
0xffff000000000000: ldr x1, [x0] 0xffff000000000004: add x1, x1, #0x10 0xffff000000000008: ldr x2, [x0, #0x10] /* ... */ 0xffff000040000000: mov x0, #0xfffffffffffffff2 // -14 0xffff000040000004: ret
假設(shè)x0寄存器保存著用戶空間地址，因此我們需要對(duì)0xffff000000000000地址的匯編指令創(chuàng)建一個(gè)exception table entry，并且我們期望當(dāng)x0是非法用戶空間地址時(shí)，跳轉(zhuǎn)返回的修復(fù)地址是0xffff000040000000。為了計(jì)算簡(jiǎn)單，假設(shè)這是創(chuàng)建第一個(gè)entry， __start___ex_table值是0xffff000080000000。那么第一個(gè)exception table entry的insn和fixup成員的值分別是：0x80000000和0xbffffffc（這兩個(gè)值都是負(fù)數(shù)）。因此，針對(duì)copy{to,from}user()匯編代碼中每一處用戶空間地址訪問(wèn)的指令都會(huì)創(chuàng)建一個(gè)entry。所以0xffff000000000008地址處的匯編指令也需要?jiǎng)?chuàng)建一個(gè)exception table entry。
所以，如果內(nèi)核態(tài)訪問(wèn)非法用戶空間地址究竟發(fā)生了什么？上面的分析流程可以總結(jié)如下：
訪問(wèn)非法用戶空間地址：
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 并且返回修復(fù)地址0xffff000040000000
do_page_fault()修改函數(shù)返回地址（regs->pc = 0xffff000040000000）并返回
程序繼續(xù)執(zhí)行，處理出錯(cuò)情況
修改函數(shù)返回值x0 = -EFAULT (-14) 并返回（ARM64通過(guò)x0傳遞函數(shù)返回值）
到了回顧總結(jié)的時(shí)候，copy_{to,from}_user()的思考也到此結(jié)束。我們來(lái)個(gè)總結(jié)結(jié)束此文。
無(wú)論是內(nèi)核態(tài)還是用戶態(tài)訪問(wèn)合法的用戶空間地址，當(dāng)虛擬地址并未建立物理地址的映射關(guān)系的時(shí)候，page fault的流程幾乎一樣，都會(huì)幫助我們申請(qǐng)物理內(nèi)存并創(chuàng)建映射關(guān)系。所以這種情況下memcpy()和copy_{to,from}_user()是類(lèi)似的。
當(dāng)內(nèi)核態(tài)訪問(wèn)非法用戶空間地址的時(shí)候，根據(jù)異常地址查找修復(fù)地址。這種修復(fù)異常的方法并不是建立地址映射關(guān)系，而是修改do_page_fault()返回地址。而memcpy()無(wú)法做到這點(diǎn)。
在使能 CONFIG_ARM64_SW_TTBR0_PAN或者 CONFIG_ARM64_PAN（硬件支持的情況下才有效）的時(shí)候，我們只能使用copy_{to,from}_user()這種接口，直接使用memcpy()是不行的。
上述就是小編為大家分享的Linux中copy_{to, from}_user()的介紹了，如果您也有類(lèi)似的疑惑，不妨參照上述方法進(jìn)行嘗試。如果想了解更多相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊。
