Android HWASAN使用與實現原理

一、背景

為了提前檢測出Android User Sapce的app或native進程的內存錯誤問題，幫助研發定位與分析這些問題，基于Android 14版本上對HWASAN做了調研分析。

二、ASAN介紹

HWASAN是在ASAN的基礎上做了拓展，因此在介紹HWASAN之前先了解下ASAN.

ASAN（AddressSanitizer）和HWASAN（Hardware-assisted AddressSanitizer）都是內存錯誤檢測工具，用于幫助開發者發現和修復內存相關的bug，如heap-buffer-overflow、Heap-use-after-free、stack-buffer-overflow、global-buffer-overflow、double-free、Use-after-return、Alloc-dealloc-mismatch、use-after-poision等內存錯誤問題。它們的主要區別在于實現方式和性能開銷。

2.1 shadow memory

shadow memory區域來記錄實際內存的狀態信息，malloc申請的內存或其它方式申請的內存一般8字節對齊，8字節的正常內存對應1個字節的shadow memory，8個字節中可劃分為可尋址（訪問）與不可尋址區域。如，前4個字節可尋址，后4個字節不可尋址，shadow memory記錄的數據為5，即0000 0100.

normal mem與shadow mem對應關系：

shadow memory address = (normal memory address >> 3) + 0x1000000000

8字節組成的normal memory region共有3種狀態：

1）1~7個字節可尋址，即shadow memory的值為1~7。

2）8個字節都可尋址，即shadow memory的值為0。

3）0個字節可尋址，shadow memory的值為負數。

0個字節可尋址其實可以分為多種情況，如：

這塊區域是heap redzones、stack redzones、global redzones、freed memory，不同錯誤類型對應的shadow memory值也不一樣。

 Addressable:           00Partially addressable: 01 02 03 04 05 06 07 Heap left redzone:     fa (實際上Heap right redzone也是fa)Freed Heap region:     fdStack left redzone:    f1Stack mid redzone:     f2Stack right redzone:   f3Stack after return:    f5Stack use after scope: f8Global redzone:        f9Global init order:     f6Poisoned by user:      f7Container overflow:    fcArray cookie:          acIntra object redzone:  bbASan internal:         feLeft alloca redzone:   caRight alloca redzone:  cbShadow gap:            cc

每次訪問normal memory地址時，都會去結合對應的shadow mem的值檢測是否合法。

2.2 ASAN實現原理

ASAN實現原理：通過在內存分配時插入額外的代碼來檢查內存訪問是否合法。使用一個影子內存（shadow memory）區域來記錄實際內存的使用情況，當檢測到非法內存訪問時，ASAN會報告錯誤。

檢測算法：

ShadowAddr = (Addr >> 3) + Offset;
k = *ShadowAddr;
if (k != 0 && ((Addr & 7) + AccessSize > k))ReportAndCrash(Addr);

k!=0，說明Normal memory region中的8個字節并不是都可以被尋址的。

Addr & 7，將得知此次內存訪問是從memory region的第幾個byte開始的。

AccessSize是此次內存訪問需要訪問的字節長度。

(Addr&7)+AccessSize > k，則說明此次內存訪問將會訪問到不可尋址的字節。

當此次內存訪問可能會訪問到不可尋址的字節時，ASAN會報錯并結合shadow memory中具體的值明確錯誤類型。

下面以use-after-free、heap-buffer-overflow來分析具體的檢測原理。

2.2.1 use-after-free檢測

檢測原理：

1）已經free的normal memory對應的shadow memory值為0xfd.

2）已經free的normal memory區域需要放入隔離區一段時間（過段時間才允許被重新分配），防止發生錯誤時該區域已經通過malloc重新分配給其他人使用。一旦分配給其他人使用，則可能漏掉UseAfterFree的錯誤。

3）如果再次訪問該normal memory區域時，發現對應的shadow memory值為0xfd，則觸發ASAN異常報錯。

2.2.2 heap-buffer-overflow檢測

檢測原理：

1）分配內存時normal memory的前后需要插入一定長度的安全區（大小不定），且此安全區對應的shadow memory被標記為0xfa.

2）當訪問越界時，剛好訪問了normal memory的前后安全區，此安全區對應的shadow memory值為0xfa，則觸發ASAN異常報錯。

2.3 ASAN缺陷

2.3.1 存在漏檢的風險

1）use-after-free檢測依賴隔離區，一段時間后這塊內存被其他模塊重新分配后，該模塊再去訪問，則無法檢測出use-after-ree的錯誤。

2）heap-buffer-overflow檢測依賴安全區，安全區有大小限制。可能是8bytes，64bytes或者其他什么值，但不管怎么樣終歸是有限的。如果某次踩踏跨過了安全區，踩踏到另一片可尋址的內存區域，則無法檢測出heap-buffer-overflow的錯誤。

2.3.2 性能開銷大

有兩個原因導致ASAN性能開銷：

1）增加額外的內存消耗：8字節的normal memory對應1個字節的shadow memory，相當于額外多出1/8的內存用于記錄正常內存的狀態信息；內存分配時需要在前后插入安全區，用于檢測越界訪問。這兩種情況都會導致內存增加。

2）效率降低：需要在每次內存訪問時進行檢查，降低了效率；被釋放的內存，需被隔離一段時間，無法立即被重新分配，系統內存緊張時，可能存在較大的性能影響

因此，針對ASAN的存在漏檢的風險和性能開銷大的缺陷，google提出了HWASAN來改善這兩大缺陷。HWASAN解決措施：

1）措施1：64位的機器，實際上ARMv8尋址只用到了低48位，因此malloc時，HWASAN利用高8位標記tag，對應的shadow memory的值也記做tag

由于HWASAN 16字節的normal memory對應1個字節的shadow memory（ASAN為8：1），降低額外內存的消耗；由于HWASAN use-after-free檢測不依賴隔離區，解決use-after-free漏檢的風險（詳細參考3.1.1）。

2）措施2：去除ASAN安全區的內存機制

由于去除ASAN安全區的內存機制，被釋放的內存可以被其他模塊立即分配，從而提高了內存的利用效率；

同時可以解決heap-buffer-overflow漏檢的風險（詳細參考3.1.2）。

三、HWASAN介紹

HWASAN是ASAN的升級版，優化了ASAN性能開銷和漏檢風險的缺陷。

3.1 實現原理

實現原理：64位的機器，實際上ARMv8尋址只用到了低48位。HWASAN用這8bit來存儲一塊內存區域的標簽(tag)。

堆內存通過malloc分配出來，HWASAN在它返回地址時會更改該有效地址的高8位，隨機生成一個tag數值，并將該tag同步到內存對應的shadow memory，當內存釋放時，更新shadow memory的tag，HWASAN中normal memory和shadow memory的映射關系是16:1，而ASAN中二者的映射關系是8:1。通過對比內存高8位的tag與shadow memory的tag是否一致，如果不一致，會觸發HWASAN相關的內存錯誤。

下面以use-after-free、heap-buffer-overflow來分析具體的檢測原理。

3.1.1 use-after-free檢測

檢測原理：

1）分配一塊內存時，內存的高8位打上tag，對應的shadow memory的值也為該tag

2）內存釋放時，更新對應的shadow memory的tag，使這塊內存的高8位的tag與shadow memory的tag不一致

3）當再次訪問這塊內存時，發現內存的高8位的tag與shadow memory的tag不一致，觸發HWASAN內存錯誤

如，char* p =new char[10]，分配10個字節的內存，由于8個字節對齊，共占用16個字節，高8位隨機生成tag1。

當內存釋放時，對應的shadow memory的值由原來的tag1更新位tag2.再次訪問p[0]時，檢查高8位tag1與shadow memory中的值tag2不一致，觸發HWASAN use-after-free.

char* p =new char[10]；
delete [] p;
p[0] = "abc";

3.1.2 heap-buffer-overflow檢測

檢測原理：

1）相鄰內存的shadow memory的tag不一致

2）當訪問這塊內存地址時，會去檢測該地址高8位的tag與對應shadow memory的tag是否一直不一致。如果不一致，說明越界訪問

如，char* p =new char[10]，分配10個字節的內存，由于8個字節對齊，共占用16個字節，高8位隨機生成tag2。當訪問p[16]時，由于p+16所處地址對應的shadow memory的值為tag3與p地址對應的高8位tag2不一致，會觸發HWASAN heap-buffer-overflow.

char* p =new char[10]；
p[16] = "abc";

由于每次malloc，高8位的tag隨機生成，因此存在相鄰內存高8位的tag一致的概率（如tag2等于tag3），概率為1/256，在這種情況下即使越界訪問，也無法檢測出heap-buffer-overflow的問題。

3.2 HWASAN優缺點

優點：

解決了ASAN的缺陷

缺點：

1）由于采用了高8位的tag檢測機制，因此只能適用于64位的機器

2）HWASAN中normal memory和shadow memory的映射關系是16:1，即會多消耗1/16的額外內存用于記錄normal memory的狀態（tag）信息

3）每次內存分配、釋放、訪問，都需要額外的檢測工作，降低性能

4.1 系統全功能打開

1）編譯帶HWASAN的鏡像和帶hwasan的libc.so & libclang_rt.hwasan-aarch64-android.so

source build/envsetup.sh
lunch missi_auto_native_only64-userdebug
export SANITIZE_TARGET=hwaddress
make -j8 或make systemimage

libc.so路徑：

out/target/product/missi/system/lib64/bootstrap/hwasan/libc.so

libclang_rt.hwasan-aarch64-android.so路徑：out/target/product/missi/system/lib64/bootstrap/libclang_rt.hwasan-aarch64-android.so

2）刷機或push libc.so和libclang_rt.hwasan-aarch64-android.so到/system/lib64目錄后重啟設備

4.2 單個應用或進程打開

AndroidManifest.xml中 <application> 元素中配置了 android:debuggable="true"

<application android:debuggable="true"></application>

native進程開啟HWASAN，需要在Android.bp中做配置：

sanitize: {hwaddress: true,
},

五、Debug案例

在設備驗證HWASAN功能：

1）設置HWASAN環境變量，編譯出帶HWASAN的鏡像或libc.so + libclang_rt.hwasan-aarch64-android.so

source build/envsetup.sh
lunch missi_auto_native_only64-userdebug
export SANITIZE_TARGET=hwaddress
make -j8 或make systemimage

帶hwasan的libc.so路徑：

out/target/product/missi/system/lib64/bootstrap/hwasan/libc.so

libclang_rt.hwasan-aarch64-android.so路徑：out/target/product/missi/system/lib64/bootstrap/libclang_rt.hwasan-aarch64-android.so

（刷機方式效率較低，可以直接push so庫到設備）

2）push libc.so和libclang_rt.hwasan-aarch64-android.so到/system/lib64目錄后重啟設備

3）自己編寫一個Demo，push hw-asan-test-bin Demo到/system/bin目錄并執行

檢測double-free、use-after-free、invalid-free、heap-over-flow等場景，

分別執行./system/bin/hw-asan-test-bin double-free、./system/bin/hw-asan-test-bin use-after-free、./system/bin/hw-asan-test-bin heap-over-flow命令。

Demo的部分代碼：

void doubleFree() {// 分配4個字節int *ptr = (int*)malloc(4);std::cout << "ptr = " << ptr << std::endl;free(ptr);free(ptr);
}void invalidFree() {int *ptr = (int*)malloc(4);std::cout << "ptr = " << ptr << std::endl;free(ptr+1);std::cout << "invalid-free ~" << std::endl;
}void useAfterFree() {char* ptr = new char[20];std::cout << "ptr = " << ptr << std::endl;delete[] ptr;ptr[0] = 'A';std::cout << "useAfterFree ~" << std::endl;
}void heapOverFlow() {char* ptr = new char[20];std::cout << "ptr = " << ptr << std::endl;ptr[32] = 'A';std::cout << "heapOverFlow ~" << std::endl;
}void memLeak() {for (int i = 0; i < 1000; i++) {char *buffer = (char *)malloc(100);}std::cout << "memLeak ~" << std::endl;
}

4）查詢生成的tombstone文件

以下是hw-asan-test-bin Demo crash生成的HWASAN tombstone文件，如下：

Cmdline: ./system/bin/hw-asan-test-bin double-free
pid: 12968, tid: 12968, name: hw-asan-test-bi  >>> ./system/bin/hw-asan-test-bin <<<
uid: 0
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
// 內存被釋放后，0x003c95840020地址對應的內存被標記為6c
Abort message: '==12968==ERROR: HWAddressSanitizer: invalid-free on address 0x003c95840020 at pc 0x007d0dd81ba4 on thread T0
tags: 77/6c (ptr/mem)#0 0x7d0dd81ba4  (/system/lib64/libclang_rt.hwasan-aarch64-android.so+0x23ba4) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#1 0x5b9584c230  (/system/bin/hw-asan-test-bin+0x1230) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#2 0x5b9584c6a4  (/system/bin/hw-asan-test-bin+0x16a4) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#3 0x7d0aab6b60  (/apex/com.android.runtime/lib64/bionic/hwasan/libc.so+0xb0b60) (BuildId: 86a860a589207e712675d7d611b13147)#4 0x5b9584c054  (/system/bin/hw-asan-test-bin+0x1054) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)[0x003c95840020,0x003c95840040) is a small unallocated heap chunk; size: 32 offset: 0Cause: use-after-free
// 分配的內存地址0x003c95840020至0x003c95840024，剛好是4個字節與Demo代碼一致
0x003c95840020 is located 0 bytes inside a 4-byte region [0x003c95840020,0x003c95840024)
// HWASAN內存釋放的堆棧信息
freed by thread T0 here:#0 0x7d0dd81ba4  (/system/lib64/libclang_rt.hwasan-aarch64-android.so+0x23ba4) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#1 0x5b9584c188  (/system/bin/hw-asan-test-bin+0x1188) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#2 0x5b9584c6a4  (/system/bin/hw-asan-test-bin+0x16a4) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#3 0x7d0aab6b60  (/apex/com.android.runtime/lib64/bionic/hwasan/libc.so+0xb0b60) (BuildId: 86a860a589207e712675d7d611b13147)#4 0x5b9584c054  (/system/bin/hw-asan-test-bin+0x1054) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)
// HWASAN內存分配的堆棧信息
previously allocated here:#0 0x7d0dd82244  (/system/lib64/libclang_rt.hwasan-aarch64-android.so+0x24244) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#1 0x7d0aa671dc  (/apex/com.android.runtime/lib64/bionic/hwasan/libc.so+0x611dc) (BuildId: 86a860a589207e712675d7d611b13147)#2 0x5b9584c0d4  (/system/bin/hw-asan-test-bin+0x10d4) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#3 0x5b9584c6a4  (/system/bin/hw-asan-test-bin+0x16a4) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#4 0x7d0aab6b60  (/apex/com.android.runtime/lib64/bionic/hwasan/libc.so+0xb0b60) (BuildId: 86a860a589207e712675d7d611b13147)#5 0x5b9584c054  (/system/bin/hw-asan-test-bin+0x1054) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)hwasan_dev_note_heap_rb_distance: 1 1023
hwasan_dev_note_num_matching_addrs: 0
hwasan_dev_note_num_matching_addrs_4b: 0
Thread: T0 0x007400002000 stack: [0x007fc95fb000,0x007fc9dfb000) sz: 8388608 tls: [0x007d0ea6efc0,0x007d0ea72000)
Memory tags around the buggy address (one tag corresponds to 16 bytes):0x003c9583f800: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583f900: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583fa00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583fb00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583fc00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583fd00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583fe00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c9583ff00: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
=>0x003c95840000: 08  00 [6c] 00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840100: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840200: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840300: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840400: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840500: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840600: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840700: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 0x003c95840800: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00 
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):0x003c9583ff00: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. 
=>0x003c95840000: 6e  .. [..] ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. 0x003c95840100: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. ......backtrace:#00 pc 00000000000bab8c  /apex/com.android.runtime/lib64/bionic/hwasan/libc.so (abort+308) (BuildId: 86a860a589207e712675d7d611b13147)#01 pc 00000000000354b4  /system/lib64/libclang_rt.hwasan-aarch64-android.so (__sanitizer::Abort()+60) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#02 pc 0000000000033d3c  /system/lib64/libclang_rt.hwasan-aarch64-android.so (__sanitizer::Die()+204) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#03 pc 00000000000286c4  /system/lib64/libclang_rt.hwasan-aarch64-android.so (__hwasan::ScopedReport::~ScopedReport()+544) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#04 pc 0000000000027458  /system/lib64/libclang_rt.hwasan-aarch64-android.so (__hwasan::ReportInvalidFree(__sanitizer::StackTrace*, unsigned long)+560) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#05 pc 0000000000023c00  /system/lib64/libclang_rt.hwasan-aarch64-android.so (__sanitizer_free+264) (BuildId: 558b5c131872716737ddc0a62f3382dd3df70b9a)#06 pc 0000000000001230  /system/bin/hw-asan-test-bin (doubleFree()+472) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#07 pc 00000000000016a4  /system/bin/hw-asan-test-bin (main+648) (BuildId: b3d99e0748a4c4a2607c8c2b9b91815e)#08 pc 00000000000b0b60  /apex/com.android.runtime/lib64/bionic/hwasan/libc.so (__libc_init+148) (BuildId: 86a860a589207e712675d7d611b13147)......