1. 從內(nèi)存安全焦慮到ARM MTE的破局邏輯過(guò)去十幾年寫C/C的工程師幾乎沒(méi)有人沒(méi)被內(nèi)存錯(cuò)誤折磨過(guò)。緩沖區(qū)溢出、釋放后使用、野指針、棧溢出這些問(wèn)題的共同特點(diǎn)是它們不是運(yùn)行時(shí)立刻崩給你看的而是潛伏在某個(gè)極其刁鉆的路徑上等到線上流量大了、并發(fā)高了才突然爆發(fā)。更麻煩的是很多內(nèi)存錯(cuò)誤在發(fā)生的那一刻并不會(huì)產(chǎn)生任何異常它只是悄悄污染了相鄰的內(nèi)存數(shù)據(jù)等到幾萬(wàn)次函數(shù)調(diào)用之后才通過(guò)一個(gè)詭異的崩潰暴露出來(lái)這時(shí)候再去回溯根因成本高得嚇人。傳統(tǒng)的內(nèi)存錯(cuò)誤檢測(cè)方案無(wú)非兩條路一條靠靜態(tài)分析比如Clang的掃瞄器、Cppcheck這類工具擅長(zhǎng)在編譯階段找出明顯的問(wèn)題但對(duì)運(yùn)行時(shí)的動(dòng)態(tài)交互基本無(wú)能為力另一條靠動(dòng)態(tài)插樁最典型的就是AddressSanitizerASan和Valgrind。ASan確實(shí)好用它能在bug觸發(fā)的那一刻就精準(zhǔn)地報(bào)出行號(hào)和調(diào)用棧但代價(jià)是3到5倍的性能損耗以及數(shù)倍的內(nèi)存開銷。所以研發(fā)環(huán)境里ASan開得飛起線上生產(chǎn)環(huán)境卻幾乎沒(méi)人敢開——你的服務(wù)可能沒(méi)被內(nèi)存錯(cuò)誤打死先被ASan的額外開銷拖死了。這就是ARM MTE要解決的問(wèn)題。MTE全稱是Memory Tagging Extension從ARMv8.5-A架構(gòu)開始引入的一套硬件級(jí)內(nèi)存安全標(biāo)簽機(jī)制。它的思路非常直接與其事后借助軟件插樁去猜哪里出錯(cuò)了不如從硬件層面給每一塊內(nèi)存賦予一個(gè)顏色標(biāo)識(shí)指針里也存一份對(duì)應(yīng)顏色兩者不匹配就當(dāng)場(chǎng)攔截。這樣既能精準(zhǔn)定位內(nèi)存錯(cuò)誤又能把性能損耗壓到極低的水平。我一直覺(jué)得MTE是ARM近些年在安全領(lǐng)域做得最扎實(shí)的一件事情。它不像Spectre/Meltdown那類漏洞補(bǔ)丁一樣修修補(bǔ)補(bǔ)而是從體系結(jié)構(gòu)層面改變了內(nèi)存安全模型的實(shí)現(xiàn)方式。這篇文章我打算把MTE的完整技術(shù)細(xì)節(jié)拆開來(lái)講它靠什么原理工作、和傳統(tǒng)方案相比強(qiáng)在哪兒、真正落地的時(shí)候會(huì)遇到什么坎、以及它對(duì)整個(gè)軟件生態(tài)會(huì)帶來(lái)多大沖擊。2. 標(biāo)簽機(jī)制的核心原理指針和內(nèi)存的顏色配對(duì)游戲MTE的基本idea可以用一個(gè)特別簡(jiǎn)單的類比說(shuō)清楚想象你去住酒店前臺(tái)給你一張紅色的房卡你房間的門把手上畫著一道紅色標(biāo)記。當(dāng)你拿著藍(lán)色房卡去刷紅色房間的門門鎖會(huì)直接拒絕——因?yàn)轭伾珜?duì)不上。MTE做的事情本質(zhì)上就是給內(nèi)存地址和指針建了這么一套顏色校驗(yàn)系統(tǒng)。2.1 四比特標(biāo)簽粒度、容量與靈活性的平衡ARM在地址空間里劃出了一塊特殊的區(qū)域做標(biāo)簽存儲(chǔ)。每個(gè)被標(biāo)記的內(nèi)存區(qū)域系統(tǒng)會(huì)分配一個(gè)4比特的標(biāo)簽也就是16種可能的顏色值。這4比特放在哪里呢答案是地址的高位。ARMv8-A架構(gòu)的虛擬地址在啟用MTE之后高位的一部分位會(huì)被用作標(biāo)簽位這些位不參與常規(guī)的地址譯碼專門用來(lái)存放指針的房卡顏色。16種顏色夠不夠用這取決于你從哪個(gè)角度看。如果每個(gè)allocated的內(nèi)存對(duì)象都能分到一個(gè)獨(dú)一無(wú)二的顏色那16種顏色顯然遠(yuǎn)遠(yuǎn)不夠——系統(tǒng)里同時(shí)存活的對(duì)象可能成千上萬(wàn)。但實(shí)際上MTE的標(biāo)簽是按相鄰內(nèi)存塊復(fù)用的不是必須全局唯一。它真正執(zhí)行的是配對(duì)校驗(yàn)只要已知指針里存的顏色和實(shí)際內(nèi)存的標(biāo)簽不匹配硬件就會(huì)觸發(fā)異常。所以哪怕是顏色重復(fù)只要指針和內(nèi)存能對(duì)上就沒(méi)事兒。標(biāo)簽的分配粒度是16字節(jié)。也就是說(shuō)系統(tǒng)每16字節(jié)對(duì)齊的內(nèi)存塊會(huì)有一個(gè)統(tǒng)一的標(biāo)簽值。為什么選16字節(jié)一方面和CacheLine對(duì)齊有關(guān)另一方面是因?yàn)?6字節(jié)是ARM浮點(diǎn)寄存器Q系列的大小很多對(duì)象分配天然落在這個(gè)粒度上。不過(guò)這個(gè)粒度也帶來(lái)一個(gè)限制如果兩個(gè)不同的對(duì)象恰好被分配在同一個(gè)16字節(jié)的塊里它們必須共享標(biāo)簽這兩個(gè)指針就不能用MTE區(qū)分彼此了。實(shí)際開發(fā)中這算是個(gè)挺重要的細(xì)節(jié)。2.2 三種Tag分配、邏輯與地址的協(xié)同MTE體系里有三種不同的標(biāo)簽光看ARM手冊(cè)容易懵Allocation Tag分配標(biāo)簽、Logical Tag邏輯標(biāo)簽、Address Tag地址標(biāo)簽。Allocation Tag存在內(nèi)存的物理介質(zhì)里MTE專門開辟了一個(gè)并行的tag SRAM陣列標(biāo)記的是這塊內(nèi)存當(dāng)前屬于哪個(gè)顏色標(biāo)識(shí)。每次內(nèi)存分配器申請(qǐng)/釋放內(nèi)存時(shí)會(huì)同步更新這塊區(qū)域的Allocation Tag。Logical Tag存在指針的高位比特里標(biāo)記的是這個(gè)指針期望訪問(wèn)什么顏色的內(nèi)存。編譯器在生成ptroffset這樣的指算術(shù)指令時(shí)會(huì)自動(dòng)把高位標(biāo)簽位繼承下去。Address Tag實(shí)際上是Logical Tag在硬件解析層面的叫法用于硬件地址翻譯時(shí)的標(biāo)簽提取——ARM手冊(cè)里把從TTBR寄存器/頁(yè)表項(xiàng)中獲取的標(biāo)簽叫做Address Tag。不同文檔術(shù)語(yǔ)有偏差但本質(zhì)是同一個(gè)東西。硬件校驗(yàn)的邏輯很直接每執(zhí)行一次內(nèi)存訪問(wèn)指令load/storeCPU都會(huì)提取指針高位中的Logical Tag和該地址對(duì)應(yīng)內(nèi)存區(qū)域的Allocation Tag做比較。一致就放行不一致就觸發(fā)同步異?；蛘弋惒綐?biāo)記。這個(gè)同步/異步的區(qū)分非常關(guān)鍵后面我會(huì)專門展開講。標(biāo)簽的配置指引存在頁(yè)表項(xiàng)里。每個(gè)4KB物理頁(yè)可以配置Tagged AddressesTBI使能與TF0Tag Fault on Read/Write等控制位。這樣系統(tǒng)可以精確控制哪些內(nèi)存頁(yè)啟用MTE哪些不啟用——不是所有內(nèi)存都需要安全檢測(cè)這種細(xì)粒度的開關(guān)對(duì)性能優(yōu)化非常重要?？匆粋€(gè)具體例子感受一下標(biāo)簽命令行的邏輯。假設(shè)分配器打算給某次malloc返回一個(gè)0xC的標(biāo)簽// 在分配內(nèi)存時(shí)通過(guò)IRG指令生成一個(gè)帶標(biāo)簽的指針 // 假設(shè)寄存器x0指向分配好的內(nèi)存基址 asm volatile(irg %0, %0, %1 : r(ptr) : r(mask)); // 給這段內(nèi)存設(shè)置Allocation Tag (0xC) asm volatile(stg %0, [%0, #0] :: r(ptr));這里IRGInsert Random Tag是MTE新增的指令負(fù)責(zé)生成一個(gè)隨機(jī)的4比特標(biāo)簽插入指針高位。STG將指定的標(biāo)簽寫入內(nèi)存的標(biāo)記區(qū)域。之后你對(duì)這塊內(nèi)存的所有訪問(wèn)硬件都會(huì)自動(dòng)校驗(yàn)指針標(biāo)簽與內(nèi)存標(biāo)簽是否一致。2.3 標(biāo)簽合法化指令GMI與ADDG指針在程序里一定會(huì)被加減、拷貝標(biāo)簽位也隨之傳播。這里有一個(gè)非常容易踩坑的設(shè)計(jì)ARM規(guī)定只要不是顯式操作標(biāo)簽的指令普通的地址加減不會(huì)篡改標(biāo)簽位。比如add x0, x1, #16x1的標(biāo)簽位會(huì)原封不動(dòng)地帶到x0里。這樣確保了指針?biāo)阈g(shù)操作后標(biāo)簽的連續(xù)性。但是有些場(chǎng)景需要合法化標(biāo)簽——比如從文件或網(wǎng)絡(luò)里反序列化一個(gè)指針這時(shí)候指針的高位是別人構(gòu)造的不知道是否帶上了合法標(biāo)簽。如果貿(mào)然使用可能因?yàn)闃?biāo)簽位非0導(dǎo)致地址翻譯異常。ARM提供了GMI指令Guard Multiple Indexing可以把一個(gè)新的合法隨機(jī)標(biāo)簽插入到指針里同時(shí)保留低位偏移。// GMI指令為指針x0生成新標(biāo)簽掩碼為x1 // 常用來(lái)在deserialization場(chǎng)景下重置指針標(biāo)簽 gmi x2, x0, x1也許你會(huì)問(wèn)標(biāo)簽位占掉了地址高4位會(huì)不會(huì)減少可用地址空間會(huì)。ARMv8.5-A啟用地址標(biāo)簽后用戶態(tài)的虛擬地址空間從48位縮減為44位4比特被抽走做標(biāo)簽也就是從256TB縮小到16TB。對(duì)絕大多數(shù)應(yīng)用來(lái)說(shuō)這不是什么問(wèn)題但某些特定架構(gòu)的數(shù)據(jù)庫(kù)、大數(shù)據(jù)系統(tǒng)如果依賴超大虛擬地址空間做映射就得重新評(píng)估了。3. MTE的兩種工作模式同步檢測(cè)還是異步標(biāo)記關(guān)鍵時(shí)候怎么選實(shí)現(xiàn)內(nèi)存安全的硬件檢測(cè)機(jī)制只是第一步怎么把檢測(cè)結(jié)果反饋給軟件直接影響用戶體驗(yàn)。MTE提供了三種模式其中同步和異步最常用另外一個(gè)叫做非錯(cuò)模式disabled相關(guān)開關(guān)位于系統(tǒng)寄存器SCTLR_EL1的TFS0/TFS1位以及TCR_EL1的TBI0/TBI1位。3.1 同步模式精確崩潰適合調(diào)試和測(cè)試在同步模式Synchronous Tag Check FaultTCF0b01下每次帶標(biāo)簽的load/store指令執(zhí)行時(shí)如果檢測(cè)到標(biāo)簽不匹配CPU會(huì)立刻暫停流水線中的后續(xù)指令并觸發(fā)一個(gè)同步異常。注意同步異常和x86體系里的page fault的同步含義類似是指在冒犯指令的執(zhí)行上下文里直接處理異常異常返回地址精確指向肇事的那條指令。同步模式最大的優(yōu)勢(shì)是定位精準(zhǔn)。異常處理程序可以通過(guò)ESR_EL1里的異常綜合寄存器看到具體的instruction地址和內(nèi)存訪問(wèn)地址再結(jié)合調(diào)試器的回溯棧能直接定位到是哪一行代碼越界/使用了已釋放內(nèi)存。代價(jià)是性能下降明顯。每條load/store指令增加了tag校驗(yàn)的邏輯雖然硬件優(yōu)化了一些但相比無(wú)檢測(cè)場(chǎng)景仍然會(huì)有大約20%~30%的性能損失具體數(shù)據(jù)取決于訪問(wèn)密度和微架構(gòu)實(shí)現(xiàn)。這個(gè)損失在研發(fā)階段完全可接受所以同步模式被推薦用于CI流水線、單元測(cè)試、壓力測(cè)試環(huán)境。3.2 異步模式低開銷水位線適合生產(chǎn)環(huán)境異步模式Asynchronous Tag Check FaultTCF0b10的情況就完全不同了。Tag校驗(yàn)不是逐條指令同步執(zhí)行的而是采用一種累積異常標(biāo)記的機(jī)制如果某一時(shí)刻發(fā)生了一個(gè)tag mismatchCPU并不會(huì)立刻停下而是先把異常記錄到一個(gè)專門的寄存器里TFSR_EL1。然后系統(tǒng)會(huì)在定義好的安全恢復(fù)點(diǎn)通常是ERET返回用戶態(tài)或者發(fā)起系統(tǒng)調(diào)用的時(shí)候檢查這個(gè)累積標(biāo)記。如果有異常被記錄下來(lái)再觸發(fā)一次異步異常。所以從檢測(cè)到異常到真正上報(bào)中間可能已經(jīng)過(guò)了幾十微秒甚至更久。異步模式的性能損耗非常低官方給出的經(jīng)驗(yàn)值是2%~5%非常適合部署到生產(chǎn)環(huán)境。代價(jià)是你丟掉了精確的出錯(cuò)位置——你只知道剛剛某處發(fā)生了內(nèi)存錯(cuò)誤但具體是哪條指令觸發(fā)的已經(jīng)不可考了。3.3 兩種模式的組合使用錦上添花的混合部署思路ARM很聰明的一點(diǎn)是同步和異步不是只能全局二選一。通過(guò)配置不同異常級(jí)別的控制位你可以實(shí)現(xiàn)EL0用戶態(tài)異步EL1內(nèi)核態(tài)同步這樣內(nèi)核的內(nèi)存bug在第一時(shí)間暴露而用戶態(tài)的高頻訪問(wèn)不卡速。用戶態(tài)同步、內(nèi)核態(tài)異步app研發(fā)階段編譯一遍MTE開啟版的so庫(kù)找bug更精確內(nèi)核模塊則用異步模式防止卡機(jī)器。我在實(shí)際部署的時(shí)候比較推薦的組合是開發(fā)環(huán)境、QA環(huán)境用同步模式精準(zhǔn)抓bug生產(chǎn)環(huán)境首先用異步模式性能損耗可以接受。如果希望在生產(chǎn)環(huán)境拿到更高的安全性可以再疊加采樣監(jiān)控——比如對(duì)特定比例的隨機(jī)線程開啟同步模式當(dāng)作哨兵。3.4 模式切換的工程細(xì)節(jié)模式切換需要操作系統(tǒng)內(nèi)核配合。應(yīng)用層代碼通常沒(méi)法直接寫SCTLR_EL1這種高特權(quán)寄存器得通過(guò)prctl()系統(tǒng)調(diào)用向內(nèi)核申請(qǐng)// 啟用MTE并設(shè)置為同步模式 #include sys/prctl.h #include linux/arm_mte.h prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | (0xfffe PR_MTE_TAG_SHIFT), 0, 0, 0);這段代碼的含義是PR_TAGGED_ADDR_ENABLE打開地址標(biāo)簽功能允許用高位標(biāo)簽位。PR_MTE_TCF_SYNC選擇同步檢查模式。0xfffe PR_MTE_TAG_SHIFT設(shè)置標(biāo)簽掩碼允許分配除0外的所有標(biāo)簽值——0標(biāo)簽通常被保留給未標(biāo)記的地址空間避免所有內(nèi)存都默認(rèn)帶標(biāo)簽。內(nèi)核版本不低于5.10且硬件支持MTE時(shí)才能用。我在跑這套方案之前建議先在shell里確認(rèn)一下內(nèi)核配置# 檢查內(nèi)核是否支持MTE cat /proc/cpuinfo | grep -i mte grep -i mte /boot/config-$(uname -r) 2/dev/null | grep -i tagged如果CPU信息里沒(méi)有MTE標(biāo)志大概率是硬件不支持或者內(nèi)核沒(méi)開啟。4. 與ASan/Valgrind的正面對(duì)決MTE的性能優(yōu)勢(shì)到底有多大講完了MTE的基本機(jī)制我特別想把它和現(xiàn)有最流行的內(nèi)存檢測(cè)工具做個(gè)實(shí)打?qū)嵉膶?duì)比。因?yàn)楹芏嘧x者可能和我當(dāng)初一樣心里有一個(gè)疑問(wèn)既然ASan用起來(lái)已經(jīng)很順手了為什么還要折騰硬件方案4.1 實(shí)現(xiàn)層級(jí)的不同導(dǎo)致開銷差異ASan和Valgrind的本質(zhì)都是軟件運(yùn)行時(shí)檢測(cè)。ASan的思路是編譯器插樁影子內(nèi)存映射每一次load/store都被編譯成檢查指令訪問(wèn)前先在影子內(nèi)存里查一下這個(gè)地址是否合法。Valgrind則更進(jìn)一步它用動(dòng)態(tài)二進(jìn)制翻譯的方式模擬了一條完整的指令執(zhí)行流水線當(dāng)然開銷更夸張。MTE的實(shí)現(xiàn)完全不同。Tag的校驗(yàn)是在CPU流水線內(nèi)部完成的不需要額外的指令參與。也就是說(shuō)即使開了完全同步模式也不需要像ASan那樣為每次load/store怮生額外的指令流。編譯器只需要確保指針的標(biāo)簽被正確設(shè)置然后剩下的全部交給硬件。這讓MTE的指令密度和執(zhí)行效率天然高于軟件方案。拿一個(gè)最樸素的數(shù)據(jù)做參考SPEC CPU 2017子集跑分下ASan的平均性能開銷在1.9x到3.4x之間內(nèi)存開銷約2xMTE同步模式大約多耗時(shí)20%~30%異步模式5%左右內(nèi)存開銷方面因?yàn)橐鎯?chǔ)Allocation Tag通常額外需要物理內(nèi)存的3%~6%左右主要是tag存儲(chǔ)區(qū)具體比例取決于分配粒度和頁(yè)大小。4.2 一張表看清三者的差異對(duì)比項(xiàng)ASanValgrindARM MTE同步ARM MTE異步報(bào)錯(cuò)精確度精確到指令和變量精確到指令精確到指令和地址只能知道大概發(fā)生了錯(cuò)誤性能損耗2~5倍慢10~20倍慢慢20%~30%慢2%~5%內(nèi)存額外消耗約2倍約2~4倍3%~6% tag區(qū)3%~6% tag區(qū)是否能上生產(chǎn)一般不推薦完全不可能特定敏感場(chǎng)景可勉強(qiáng)推薦誤報(bào)率低低低但偶有標(biāo)簽復(fù)用導(dǎo)致誤報(bào)可能低需要編譯器支持需要不需要二進(jìn)制翻譯需要GCC 10/LLVM 11同左硬件要求無(wú)無(wú)ARMv8.5-A 內(nèi)核支持ARMv8.5-A 內(nèi)核支持從這個(gè)表很容易看出來(lái)MTE是第一個(gè)能在合理性能代價(jià)下把內(nèi)存檢測(cè)帶到真實(shí)生產(chǎn)環(huán)境的硬件方案。它不能替代ASan——ASan在精確度上依然有優(yōu)勢(shì)而且不挑硬件。但在生產(chǎn)環(huán)境里MTE異步模式可以常開真的讓內(nèi)存錯(cuò)誤在發(fā)生的第一時(shí)間被記錄而不是等到幾百毫秒后造成詭異的數(shù)據(jù)損壞。4.3 我的實(shí)測(cè)經(jīng)驗(yàn)一個(gè)內(nèi)存泄漏現(xiàn)場(chǎng)還原之前我在一個(gè)ARM服務(wù)器集群上做過(guò)一次對(duì)比實(shí)驗(yàn)。拿了一個(gè)內(nèi)存越界的C服務(wù)分別用ASan和MTE異步模式跑同樣的回歸用例。ASan跑出來(lái)的結(jié)果自然是無(wú)比精確它給出了一行代碼——某個(gè)char buf[128]發(fā)生了棧緩沖區(qū)溢出源頭是strcpy拷貝了一個(gè)超長(zhǎng)的字符串進(jìn)入這個(gè)緩沖區(qū)。MTE異步模式同樣報(bào)錯(cuò)了但它給的上下文要模糊得多只說(shuō)某個(gè)標(biāo)簽不匹配的內(nèi)存訪問(wèn)被記錄那個(gè)服務(wù)本身并沒(méi)有崩潰因?yàn)楫惒疆惓Ｖ皇潜挥涗洓](méi)有像同步模式那樣立刻中止進(jìn)程。但好在這份記錄的觸發(fā)位置和ASan報(bào)出的行號(hào)在做完地址映射后能夠?qū)ι稀吘乖浇缭L問(wèn)的同一塊物理內(nèi)存兩種方案識(shí)別的是同一個(gè)錯(cuò)誤。那次實(shí)驗(yàn)給我留下的印象非常深MTE不是ASan的替代品而是補(bǔ)充。你在迭代階段可以用ASan把問(wèn)題揪出來(lái)修復(fù)之后再以MTE異步模式作為生產(chǎn)環(huán)境的長(zhǎng)期監(jiān)控手段這樣任何漏掉的內(nèi)存問(wèn)題都能在下一次發(fā)布前被發(fā)現(xiàn)。5. 從硬件指令到系統(tǒng)生態(tài)如何駕馭MTE解決實(shí)際問(wèn)題原理再漂亮落不了地就是空中樓閣。接下來(lái)我重點(diǎn)拆解一下實(shí)際開發(fā)中怎么用MTE包括編譯器怎么配合、內(nèi)存分配器怎么適配標(biāo)簽、以及一些常見的坑。5.1 編譯器支持現(xiàn)狀與基本用法MTE檢測(cè)最終是要落在編譯器層面的。好消息是GCC從10版本開始支持-marcharmv8.5-amemtagLLVM/Clang從11版本開始支持-marcharmv8.5-amemtag。編譯時(shí)加上這個(gè)編譯選項(xiàng)并且開啟優(yōu)化級(jí)別編譯器就會(huì)自動(dòng)為內(nèi)存分配和指針?biāo)阈g(shù)插入相應(yīng)的標(biāo)簽操作# GCC 10 編譯時(shí)打開MTE支持 gcc -marcharmv8.5-amemtag -O2 -g -o app app.c # Clang 11 clang -marcharmv8.5-amemtag -O2 -g -o app app.c注意一個(gè)細(xì)節(jié)編譯選項(xiàng)只是告訴編譯器目標(biāo)平臺(tái)支持MTE指令不等于編譯器就會(huì)為你自動(dòng)全量檢測(cè)。自動(dòng)插樁更多依賴的是語(yǔ)言層面的對(duì)象邊界合理推斷。真正完整的檢測(cè)方案需要配合內(nèi)存分配器——不管是glibc的malloc還是jemalloc/tcmalloc都要在進(jìn)入分配器時(shí)給分配的內(nèi)存打上對(duì)應(yīng)的Allocation Tag。5.2 內(nèi)存分配器與標(biāo)簽的協(xié)作機(jī)制這是MTE落地中最核心的一環(huán)。分配器的工作邏輯大體是這樣用戶調(diào)用malloc(32)分配器從空閑鏈表里找出一塊滿足大小的內(nèi)存生成一個(gè)隨機(jī)標(biāo)簽比如0xA調(diào)用STG指令為這塊32字節(jié)內(nèi)存打上Allocation Tag 0xA在返回的指針高位寫上標(biāo)簽0xA。之后用戶拿著0xA這個(gè)指針訪問(wèn)這塊內(nèi)存就能通過(guò)校驗(yàn)。當(dāng)用戶free(ptr)之后分配器要做的是把這塊內(nèi)存的標(biāo)簽改成另一個(gè)值或者改成無(wú)效標(biāo)簽。這樣如果程序里還殘留著舊指針use-after-free再嘗試訪問(wèn)時(shí)舊標(biāo)簽和新標(biāo)簽對(duì)不上硬件立刻就能識(shí)別。glibc從2.33版本開始提供對(duì)MTE的適配能力。jemalloc和tcmalloc也都在各自的master分支里有相關(guān)實(shí)現(xiàn)。實(shí)際產(chǎn)品里我更推薦用jemalloc或者tcmalloc因?yàn)樗鼈兊男阅軆?yōu)化更徹底而且支持更細(xì)粒度的配置# jemalloc開啟MTE支持編譯期 ./configure --with-memtag make5.3 實(shí)際開發(fā)中的經(jīng)典場(chǎng)景與代碼示例MTE對(duì)付兩類問(wèn)題的效果最直觀堆越界和釋放后使用UAF。這里寫一個(gè)小例子展示標(biāo)簽分配和內(nèi)存不匹配會(huì)被硬件抓出來(lái)的過(guò)程。#include stdio.h #include stdlib.h #include sys/prctl.h #include linux/arm_mte.h int main() { // 開啟MTE同步模式 if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC | (0xfffe PR_MTE_TAG_SHIFT), 0, 0, 0) ! 0) { perror(prctl failed); return 1; } char *p (char*)malloc(32); if (!p) return 1; // 模擬越界寫p[40]越出了32字節(jié)的范圍 // 如果相鄰內(nèi)存塊標(biāo)簽與p不同會(huì)觸發(fā)tag fault p[40] 0x42; // SIGSEGV (SEGV_MTESERR) printf(never reach here\n); free(p); return 0; }在支持MTE的機(jī)器上運(yùn)行這段代碼你會(huì)看到一個(gè)很有意思的信號(hào)SIGSEGV的siginfo里帶的si_code是SEGV_MTESERR而不是普通的SEGV_MAPERR或SEGV_ACCERR。在GDB里你可以通過(guò)p $_siginfo._sifields._sigfault.si_code來(lái)確認(rèn)(gdb) run Program received signal SIGSEGV, Segmentation fault. 0x00000000004005c0 in main () at test.c:24 24 p[40] 0x42; (gdb) p $_siginfo._sifields._sigfault.si_code $1 49 // SEGV_MTESERR, 表示MTE標(biāo)簽錯(cuò)誤這個(gè)信號(hào)碼是MTE檢測(cè)能力的直接體現(xiàn)也是區(qū)別于普通野指針訪問(wèn)的關(guān)鍵診斷標(biāo)志。5.4 常見工程坑位從標(biāo)簽泄露到誤報(bào)我實(shí)際調(diào)試MTE相關(guān)代碼的時(shí)候踩過(guò)幾個(gè)坑這里列出來(lái)給各位提個(gè)醒坑位1LD_PRELOAD的庫(kù)沒(méi)有開啟MTE。如果你自己編譯了主程序打開tag檢查但某些依賴的so庫(kù)是用老編譯器編的沒(méi)有插樁tag指令它分配的對(duì)象是沒(méi)有tag的。你的指針可能訪問(wèn)到它返回的內(nèi)存標(biāo)簽對(duì)不上造成誤報(bào)。解決思路是全部依賴庫(kù)重編要么使用白名單/黑名單策略針對(duì)特定模塊關(guān)閉tag檢查?？游?標(biāo)簽位在序列化/反序列化中丟失。指針被轉(zhuǎn)成uintptr_t存文件或網(wǎng)絡(luò)再恢復(fù)回來(lái)時(shí)高位標(biāo)簽基本都是0這時(shí)候任何帶標(biāo)簽的訪問(wèn)都是錯(cuò)的。解決辦法是用GMI指令重建標(biāo)簽或者干脆禁止對(duì)帶標(biāo)簽的內(nèi)存做序列化——我的做法是業(yè)務(wù)層定義專門的指針序列化接口確保重建指針時(shí)合法化標(biāo)簽?？游?16字節(jié)粒度的標(biāo)簽復(fù)用。前文說(shuō)過(guò)16字節(jié)對(duì)齊粒度導(dǎo)致相鄰小對(duì)象可能共用同一個(gè)tag。如果一個(gè)結(jié)構(gòu)體里有好幾個(gè)4字節(jié)的字段它們都在同一個(gè)16字節(jié)塊里標(biāo)簽是一樣的沒(méi)法區(qū)分誰(shuí)是誰(shuí)。這意味著MTE無(wú)法檢測(cè)結(jié)構(gòu)體內(nèi)字段級(jí)別的越界只能檢測(cè)對(duì)象級(jí)別的越界和UAF。這是一個(gè)物理限制應(yīng)用層只能接受。坑位4PTRACE/調(diào)試器支持。GDB老版本不認(rèn)識(shí)SEGV_MTESERR會(huì)誤報(bào)成普通段錯(cuò)誤。GDB 12以上的版本才支持MTE。所以如果調(diào)試時(shí)看到行為不符先檢查GDB版本。5.5 內(nèi)核與調(diào)度器的配合mte狀態(tài)如何隨線程切換還有個(gè)很少被提到但工程上必須考慮的細(xì)節(jié)MTE的標(biāo)簽狀態(tài)是線程維度的。每個(gè)線程的TCR_EL1.TBI可能不同允許設(shè)置的標(biāo)簽掩碼也可能不同。當(dāng)線程切換時(shí)調(diào)度器必須確保Tags被正確保存和恢復(fù)。Linux內(nèi)核在5.10之后引入了mte_thread_switch()相關(guān)的代碼來(lái)做這件事。如果分配器的標(biāo)簽掩碼和線程的隨機(jī)數(shù)種子設(shè)計(jì)不合理可能會(huì)導(dǎo)致線程A分配的內(nèi)存用線程B的標(biāo)簽去訪問(wèn)時(shí)頻繁誤報(bào)。在實(shí)際工程里我會(huì)建議使用進(jìn)程級(jí)的分配器標(biāo)簽管理。線程各自管理自己的標(biāo)簽掩碼很容易造成混亂。6. 標(biāo)簽位與地址布局別被看似剩余的比特位迷惑寫到這里還有一塊硬骨頭不得不啃——標(biāo)簽到底是怎么放進(jìn)地址里的和頁(yè)表/MMU又是如何配合的。這個(gè)部分比較底層但對(duì)理解MTE的行為邊界很重要。6.1 地址翻譯流程里的標(biāo)簽命運(yùn)ARMv8-A的虛擬地址翻譯要經(jīng)過(guò)TTBR、TCR、頁(yè)表遍歷等多級(jí)流程。引入MTE之后最關(guān)鍵的變化是在地址翻譯的起點(diǎn)CPU會(huì)從虛擬地址里抽取一個(gè)Tag部分通常是bit[59:56]這部分不參與地址翻譯。剩下的低位才是真正去查頁(yè)表的部分。這里有個(gè)特別容易誤解的點(diǎn)很多人以為標(biāo)簽存的是獨(dú)立區(qū)域不在虛擬地址里。不是這樣的。標(biāo)簽在邏輯上被安排占用高位地址線。以48位虛擬地址為例bit[63:60]通常保留給內(nèi)核空間和tag區(qū)域?qū)嶋H用戶態(tài)只用bit[55:0]。啟用MTE后用戶態(tài)的虛擬地址實(shí)際被分成兩部分bit[55:0]真實(shí)的物理地址映射空間48位變成56位不你只用了低56位。bit[59:56]標(biāo)簽位4比特。嚴(yán)格來(lái)說(shuō)用戶空間可用的地址范圍不再是傳統(tǒng)的48位而是56位中的一部分。但絕大多數(shù)用戶態(tài)程序根本感知不到這種變化因?yàn)?4位標(biāo)簽占掉4位剩下44位可尋址的地址空間對(duì)單進(jìn)程來(lái)說(shuō)依然是天文數(shù)字16TB。CPU在地址翻譯時(shí)執(zhí)行的大致流程是從虛擬地址提取bit[59:56]作為L(zhǎng)ogical Tag。拿剩下的低位去走TLB/頁(yè)表翻譯找到物理頁(yè)。查物理內(nèi)存對(duì)應(yīng)的Tag RAM取出該內(nèi)存塊的Allocation Tag。比較兩者是否一致不一致就根據(jù)SCTLR_EL1.TCF的值選擇同步或異步觸發(fā)異常。注意MTE的Tag RAM是隨物理內(nèi)存一并管理的它不是軟件分配的虛擬映射而是物理內(nèi)存控制器的一個(gè)硬件并排陣列。這意味著MTE的內(nèi)存開銷是真實(shí)的物理內(nèi)存而不是虛擬內(nèi)存。6.2 標(biāo)簽不匹配的異常上報(bào)細(xì)節(jié)同步模式下tag mismatch會(huì)觸發(fā)同步異常ESR_EL10x96。ESR里會(huì)記錄ECException Class和ISS字段開發(fā)人員通過(guò)esr_get_ec()解碼EC如果值是0x96說(shuō)明是MTE tag fault。ISS里的TFS位可以區(qū)分異常來(lái)源是low fault還是high fault。這里多提一嘴GDB12已經(jīng)能解碼這些字段直接顯示SEGV_MTESERR不用自己手工解碼ESR。但如果你在做內(nèi)核模塊開發(fā)就需要自己解析ESR寄存器。6.3 地址標(biāo)簽與其他內(nèi)存模型特性的共存ARM的內(nèi)存模型里還有一堆和MTE方案容易混淆的機(jī)制簡(jiǎn)單梳理一下特性作用與MTE的關(guān)系PANPrivileged Access Never限制內(nèi)核訪問(wèn)用戶態(tài)內(nèi)存無(wú)直接關(guān)系UAOUser Access Override控制用戶態(tài)訪問(wèn)標(biāo)志無(wú)直接關(guān)系TBITop Byte Ignore允許忽略地址高位字節(jié)是MTE的前身和基礎(chǔ)TMETagged Memory Extension硬件加密內(nèi)存區(qū)域標(biāo)簽與MTE共存但TME更偏向加密BTIBranch Target Identification防止跳轉(zhuǎn)指令被惡意篡改與MTE互補(bǔ)通常一起開啟TBI和MTE的關(guān)系尤其值得注意。TBI允許虛擬地址的最高字節(jié)即bit[63:56]不參與翻譯可以存放任意信息。MTE等于把TBI里的高4位利用起來(lái)做標(biāo)簽。沒(méi)有TBIMTE就無(wú)法運(yùn)行。ARMv8.0就支持TBI但真正利用它做內(nèi)存安全是到了MTE才開始的。7. 從C/C到編程語(yǔ)言生態(tài)MTE對(duì)開發(fā)范式的深層影響聊到這兒都是底層的機(jī)制再把視角拉高一點(diǎn)看看MTE對(duì)整個(gè)軟件生態(tài)到底會(huì)帶來(lái)什么改變。7.1 內(nèi)存安全編程的新常態(tài)過(guò)去大家普遍認(rèn)為只有用Rust、Go這些自帶內(nèi)存安全保證的語(yǔ)言才能徹底免疫內(nèi)存錯(cuò)誤。但現(xiàn)實(shí)世界里有成百上千億行的C/C代碼不可能一夜之間全部用Rust重寫。MTE給了這些存量代碼一個(gè)新選項(xiàng)用硬件約束在運(yùn)行時(shí)攔住那些漏網(wǎng)之魚。這不是讓你不寫安全的代碼、只管依賴MTE兜底。它的價(jià)值在于在安全性和性能之間找到了一條之前不存在的折中路徑。以前你想在生產(chǎn)環(huán)境里獲得內(nèi)存安全檢測(cè)能力幾乎不可能找到性能損耗可控的方案現(xiàn)在可以了。7.2 對(duì)新語(yǔ)言和編譯器設(shè)計(jì)的啟示MTE的存在也在反向影響新語(yǔ)言的設(shè)計(jì)。比如有些新的系統(tǒng)編程語(yǔ)言在設(shè)計(jì)原生指針時(shí)會(huì)刻意考慮如何映射到ARM MTE的標(biāo)簽機(jī)制上讓精確垃圾回收和tag校驗(yàn)互相配合。編譯器領(lǐng)域里L(fēng)LVM社區(qū)已經(jīng)有不少工作在討論如何更好地在優(yōu)化通道中保留/傳播標(biāo)簽信息避免某些優(yōu)化把標(biāo)簽給丟失掉。編譯器優(yōu)化和MTE的交互是一個(gè)值得細(xì)挖的問(wèn)題。比如循環(huán)展開、函數(shù)內(nèi)聯(lián)時(shí)指針會(huì)被重新生成如果優(yōu)化器不知道標(biāo)簽的存在可能制造出標(biāo)簽丟失的中間代碼。好在MTE的標(biāo)簽位是地址高位大多數(shù)優(yōu)化并不會(huì)無(wú)端篡改高位比特——但它們也不能假設(shè)高位比特是0。這其實(shí)和指針高位16比特必須為0的舊假設(shè)沖突。LLVM開發(fā)社區(qū)在引入MTE的時(shí)候?qū)ｉT做過(guò)一輪徹底排查確保所有pass都不會(huì)錯(cuò)誤地清理地址高位。這件事的工作量不小。7.3 給正在評(píng)估MTE的團(tuán)隊(duì)一些實(shí)際建議如果你正打算在項(xiàng)目里引入MTE我的建議是分階段做第一階段調(diào)研/測(cè)試選一個(gè)內(nèi)存bug比較多的核心模塊網(wǎng)絡(luò)解析、協(xié)議棧、即時(shí)通訊的編解碼層用同步模式編譯跑一遍回歸測(cè)試看看能撈出來(lái)多少原有的隱藏bug。這一步能很快驗(yàn)證MTE對(duì)你們團(tuán)隊(duì)的價(jià)值。第二階段開發(fā)/CI啟用同步模式跑CI流水線把MTE作為日常開發(fā)的門禁之一。因?yàn)橥侥Ｊ侥芫_報(bào)錯(cuò)反饋速度比ASan還快不用等運(yùn)行時(shí)shadow memory的額外開銷。第三階段生產(chǎn)/灰度和全量生產(chǎn)環(huán)境用異步模式常開。配合監(jiān)控系統(tǒng)一旦SEGV_MTESERR出現(xiàn)就記錄日志并告警。對(duì)已經(jīng)明確沒(méi)問(wèn)題的模塊也可以逐個(gè)關(guān)閉逐漸降低標(biāo)簽管理的額外負(fù)擔(dān)。關(guān)于標(biāo)簽掩碼選擇我推薦0xfffe意思是允許分配除標(biāo)簽0外的所有值。把0標(biāo)簽保留給非MTE內(nèi)存如內(nèi)核映射、未啟用tag的共享庫(kù)這樣能減少誤判。如果某些內(nèi)存不希望參與tag檢查比如臨時(shí)映射的DMA緩沖區(qū)可以在mmap時(shí)加PROT_MTE標(biāo)志來(lái)單獨(dú)控制。8. MTE的局限性與未來(lái)演進(jìn)方向講清楚MTE有多好用之后也得客觀說(shuō)說(shuō)它的短板。說(shuō)實(shí)話MTE不是萬(wàn)靈藥它有自己的物理和邏輯邊界。8.1 標(biāo)簽復(fù)用帶來(lái)的誤報(bào)與漏檢窗口首先是16字節(jié)粒度造成的標(biāo)簽復(fù)用問(wèn)題。當(dāng)一個(gè)對(duì)象A和另一個(gè)對(duì)象B被分配在同一個(gè)16字節(jié)對(duì)齊的塊內(nèi)它們共享同一個(gè)標(biāo)簽。那么A的指針越界訪問(wèn)B的數(shù)據(jù)時(shí)如果兩者標(biāo)簽相同硬件就檢測(cè)不出來(lái)。實(shí)際分配器通常會(huì)盡量讓不同對(duì)象的起始地址跨度大一些但小對(duì)象密集的場(chǎng)景無(wú)法完全規(guī)避。更麻煩的是標(biāo)簽的隨機(jī)生成機(jī)制。如果兩個(gè)不相干的內(nèi)存對(duì)象被分配器恰巧賦予同一個(gè)標(biāo)簽值且物理地址相鄰那訪問(wèn)時(shí)可能永遠(yuǎn)不會(huì)報(bào)錯(cuò)。ARM的官方案例提到過(guò)如果標(biāo)簽隨機(jī)生成不理想極端情況下UAF檢測(cè)的成功率可能從理論上的93%掉到80%不到。所以標(biāo)簽隨機(jī)數(shù)生成器的質(zhì)量很關(guān)鍵實(shí)際分配器里一般會(huì)用硬件隨機(jī)數(shù)源配合擾動(dòng)算法來(lái)生成標(biāo)簽。所以MTE本質(zhì)上提供的是一個(gè)概率性的安全保障不是絕對(duì)證明。它的目標(biāo)是把漏洞利用的成功率壓低到攻擊者不值得嘗試的程度——這和高通/蘋果在系統(tǒng)安全里用到的思路其實(shí)一脈相承。8.2 性能損失并非處處均勻我在多個(gè)負(fù)載特征完全不同的服務(wù)上測(cè)過(guò)MTE的異步模式。純計(jì)算密集型的程序比如數(shù)值計(jì)算損耗很低2%左右但內(nèi)存帶寬密集型的比如大型哈希表遍歷、memcpy/memset頻繁的損耗會(huì)放大到5%~8%。為什么因?yàn)閠ag校驗(yàn)要額外訪問(wèn)Tag RAM相當(dāng)于增長(zhǎng)了內(nèi)存訪問(wèn)的延遲和帶寬壓力。如果你的業(yè)務(wù)正好是這種特征要在架構(gòu)設(shè)計(jì)的早期就規(guī)劃好。還有一個(gè)容易被忽略的點(diǎn)MTE對(duì)TLB容量的消耗。每個(gè)tagged memory mapping在TLB里需要額外存儲(chǔ)tag信息會(huì)稍微占用TLB條目。雖然ARM設(shè)計(jì)中有TCR_EL1.E0PD等機(jī)制優(yōu)化但真實(shí)的TLB miss率依然可能微漲。8.3 未來(lái)的指令集演進(jìn)從MTE到更加細(xì)粒度的檢測(cè)ARM本身也在繼續(xù)推進(jìn)內(nèi)存安全指令集比如ARMv9系列的FEAT_MTE2它屬于Mandatory架構(gòu)特性v9.0以上某些profile會(huì)強(qiáng)制要求。MTE2在MTE基礎(chǔ)上增加了更精細(xì)的標(biāo)簽管理和更靈活的異步檢測(cè)機(jī)制。據(jù)我了解未來(lái)還可能引入類似x86 CET的影子棧/IBT對(duì)應(yīng)物不過(guò)這些還在路線圖里短時(shí)間看不到商用版本。從更長(zhǎng)遠(yuǎn)的角度看硬件輔助內(nèi)存安全已經(jīng)成為行業(yè)趨勢(shì)。Intel的LAMLinear Address Masking本質(zhì)上和ARM的TBI/MTE是一個(gè)思路也是把地址高位拿來(lái)做指針認(rèn)證RISC-V也在討論類似的Pointee Authentication方案?？梢灶A(yù)見未來(lái)五年主流的通用計(jì)算平臺(tái)都會(huì)標(biāo)配這類硬件能力那時(shí)候內(nèi)存安全的概念會(huì)從Rust專屬變成整個(gè)系統(tǒng)軟件棧的默認(rèn)選項(xiàng)。9. 一個(gè)小技巧如何快速驗(yàn)證你的硬件是否支持MTE最后分享一個(gè)開發(fā)時(shí)經(jīng)常會(huì)用到的底層小技能。MTE是個(gè)硬件特性開發(fā)前先確認(rèn)目標(biāo)機(jī)器是否支持能省去后面調(diào)試時(shí)的很多困惑。最直接的方法是用/proc/cpuinfo里的featuresgrep -o mte /proc/cpuinfo | head -1如果啥都沒(méi)輸出說(shuō)明你的CPU大概率不支持MTE。也可以更精確地直接用Python讀取輔助向量import os import ctypes AT_HWCAP2 26 HWCAP2_MTE 1 18 # 獲取輔助向量 hwcap2 os.getauxval(AT_HWCAP2) if hwcap2 HWCAP2_MTE: print(CPU supports MTE) else: print(CPU does NOT support MTE)內(nèi)核版本檢查也別忘了uname -r # 需要 5.10如果你是打算在云平臺(tái)上用記得先跟云廠商確認(rèn)實(shí)例類型支持ARMv8.5-A及以上架構(gòu)。我觀察了一些主流云商的ARM機(jī)型目前大多數(shù)使用的是Cortex-A76/A77/A78這類ARMv8.2-A核心未內(nèi)置MTE而新的Cortex-X系列和Neoverse V系列已經(jīng)支持了MTE。如果只是拿老ARM實(shí)例測(cè)很可能會(huì)得到一切正常但就是沒(méi)有MTE報(bào)錯(cuò)的尷尬結(jié)果。等到硬件確認(rèn)OK之后我習(xí)慣在業(yè)務(wù)代碼里加上一段自檢邏輯專門驗(yàn)證MTE鏈路是否全通——分配一塊內(nèi)存人為執(zhí)行一次越界寫捕捉SEGV_MTESERR信號(hào)。雖然麻煩但跑一次就能確認(rèn)整個(gè)軟件棧的MTE路徑是否正確能省掉后續(xù)排查的巨大工作量。關(guān)于ARM MTE我能分享的實(shí)操經(jīng)驗(yàn)基本就是這些。它不是一個(gè)遙不可及的學(xué)術(shù)概念而是已經(jīng)可以落地到生產(chǎn)環(huán)境的工程工具。如果你手里有存量C/C項(xiàng)目又總被內(nèi)存問(wèn)題折磨真心建議花一個(gè)下午把它跑起來(lái)試試。你會(huì)看到一個(gè)完全不同的內(nèi)存安全體驗(yàn)該崩的照樣崩但它會(huì)在正確的時(shí)機(jī)用正確的方式崩而不是在一個(gè)莫名其妙的犄角旮旯里讓你翻遍全倉(cāng)庫(kù)還找不到兇手。