一、知識(shí)背景

隨著2003年10月安迪魯賓聯(lián)合幾位朋友創(chuàng)建了Android公司，后來影響眾人的智能設(shè)備操作系統(tǒng)公司由此而生（2005年被Google收購(gòu)）?，F(xiàn)如今，世界上越來越多的智能終端包括手機(jī)、TV、SmartBox和IoT、汽車、多媒體設(shè)備等等，均深度使用Android系統(tǒng)，而Android的底層正是Linux內(nèi)核，這也讓Linux內(nèi)核的安全性對(duì)Android產(chǎn)生重大影響。

但由于Android由于想繞過商業(yè)授權(quán)的問題，又研究出來了以bionic取代Glibc、以Skia取代Cairo等類似的方案，使用的不是標(biāo)準(zhǔn)內(nèi)核和GNU/Linux。由于這些原因，Google在Android內(nèi)核開源的問題上，理念和Linux內(nèi)核社區(qū)不是十分的匹配，這也導(dǎo)致了Android對(duì)內(nèi)核做了大量的針對(duì)性修改，但是無法合入到Upstream上。這也導(dǎo)致了Android內(nèi)核在安全側(cè)有部分不同于Linux內(nèi)核，側(cè)重點(diǎn)也存在不同。

在操作系統(tǒng)級(jí)別，Android平臺(tái)不僅提供Linux內(nèi)核的安全功能，而且還提供安全的進(jìn)程間通信 (IPC)機(jī)制，以便在不同進(jìn)程中運(yùn)行的應(yīng)用之間安全通信。操作系統(tǒng)級(jí)別的這些安全功能旨在確保即使是原生代碼也要受應(yīng)用沙盒的限制。無論相應(yīng)代碼是自帶應(yīng)用行為導(dǎo)致的結(jié)果，還是利用應(yīng)用漏洞導(dǎo)致的結(jié)果，系統(tǒng)都能防止違規(guī)應(yīng)用危害其他應(yīng)用、Android 系統(tǒng)或設(shè)備本身。

以下配置設(shè)置用作Android 內(nèi)核配置的基礎(chǔ)。設(shè)置會(huì)整理android-base和android- recommended.cfg 文件，android-base.cfg 和 android-recommended.cfg 文件均位于 android-common內(nèi)核repo：https://android.googlesource.com/kernel/common/。

• android-base這些選項(xiàng)可實(shí)現(xiàn)核心Android功能，所有設(shè)備都應(yīng)該啟用。
• android-recommended這些選項(xiàng)可實(shí)現(xiàn)高級(jí)Android功能，設(shè)備可選擇性啟用。

上游Linux內(nèi)核 4.8 版本中為內(nèi)核配置片段指定了新的位置 (kernel/configs)。對(duì)于基于版本 4.8 或更高版本的分支，Android基礎(chǔ)和建議的配置片段位于該目錄中。對(duì)于基于版本 4.8 之前版本的內(nèi)核分支，配置片段位于android/目錄中。

二、生成內(nèi)核配置

對(duì)于具有極簡(jiǎn)defconfig的設(shè)備，您可以使用以下命令來啟用選項(xiàng),生成一個(gè).config文件，使用該文件來保存新的defconfig或編譯一個(gè)啟用Android功能的新內(nèi)核：

ARCH=arch scripts/kconfig/merge_config.sh path/device_defconfig android/configs/android-base.cfg android/configs/android-recommended.cfg

三、Seccomp-BPF與TSYNC

Seccomp-BPF是一種內(nèi)核安全技術(shù)，支持創(chuàng)建沙盒來限制進(jìn)程可以進(jìn)行的系統(tǒng)調(diào)用。TSYNC功能可以實(shí)現(xiàn)從多線程程序中使用Seccomp-BPF。這種能力僅限具有seccomp支持上游的架構(gòu)：ARM、ARM64、x86 和 x86_64。用于ARM-32、X86、X86_64的內(nèi)核3.10向后移植,確保Kconfig中已啟用CONFIG_SECCOMP_FILTER=y（截至Android 5.0 CTS已驗(yàn)證），然后擇優(yōu)挑選來自AOSP kernel/common:android-3.10存儲(chǔ)區(qū)的以下變更：9499cd23f9d05ba159fac6d55dc35a7f49f9ce76…a9ba4285aa5722a3b4d84888e78ba8adc0046b28?

1．cfc7e99e9 arm64: Add _NR* definitions for compat syscalls

（arm64：為兼容性系統(tǒng)調(diào)用添加 _NR* 定義），作者：JP Abgrall

2．bf11863 arm64: Add audit support

（arm64：添加審計(jì)支持），作者：AKASHI Takahiro

3．3e21c0b arm64: audit: Add audit hook in syscall_trace_enter/exit()

（arm64：審計(jì)：在 syscall_trace_enter/exit() 中添加審計(jì)鉤），作者：JP Abgrall

4．9499cd2 syscall_get_arch: remove useless function arguments

（syscall_get_arch：移除無用的函數(shù)參數(shù)），作者：Eric Paris

5．2a30a43 seccomp: create internal mode-setting function

（seccomp：創(chuàng)建內(nèi)部 mode-setting函數(shù)），作者：Kees Cook

6．b8a9cff seccomp: extract check/assign mode helpers

（seccomp：提取檢查/分配模式幫助程序），作者：Kees Cook

7．8908dde seccomp: split mode setting routines

（seccomp：拆分模式設(shè)置例行程序），作者：Kees Cook

8．e985fd4 seccomp: add “seccomp” syscall

（seccomp：添加“seccomp”系統(tǒng)調(diào)用），作者：Kees Cook

9．9d0ff69 sched: move no_new_privs into new atomic flags

（sched：將 no_new_privs 移至新的原子標(biāo)志中），作者：Kees Cook

10．b6a12bf seccomp: split filter prep from check and apply

（seccomp：將過濾器準(zhǔn)備工作從檢查和應(yīng)用流程中分離出來），作者：Kees Cook

11．61b6b88 seccomp: introduce writer locking

（seccomp：引入寫入者鎖定），作者：Kees Cook

12．c852ef7 seccomp: allow mode setting across threads

（seccomp：允許跨線程模式設(shè)置），作者：Kees Cook

13．f14a5db seccomp: implement SECCOMP_FILTER_FLAG_TSYNC

（seccomp：實(shí)施 SECCOMP_FILTER_FLAG_TSYNC），作者：Kees Cook

14．9ac8600 seccomp: Replace BUG(!spin_is_locked()) with assert_spin_lock

（seccomp：用 assert_spin_lock 替換 BUG(!spin_is_locked())），作者：Guenter Roeck

15．900e9fd seccomp: fix syscall numbers for x86 and x86_64

（seccomp：修復(fù) x86 和 x86_64 的系統(tǒng)調(diào)用號(hào)），作者：Lee Campbell

16．a(chǎn)9ba428 ARM: add seccomp syscall

（ARM：添加 seccomp 系統(tǒng)調(diào)用），作者：Kees Cook

17．4190090 ARM: 8087/1: ptrace: reload syscall number after secure_computing() check

（ARM：8087/1：ptrace：在 secure_computing() 檢查后重新加載系統(tǒng)調(diào)用號(hào)），作者：Will Deacon

18．a(chǎn)bbfed9 arm64: ptrace: add PTRACE_SET_SYSCALL

（arm64：ptrace：添加 PTRACE_SET_SYSCALL），作者：AKASHI Takahiro

19．feb2843 arm64: ptrace: allow tracer to skip a system call

（arm64：ptrace：允許跟蹤進(jìn)程跳過系統(tǒng)調(diào)用），作者：AKASHI Takahiro

20．dab1073 asm-generic: add generic seccomp.h for secure computing mode 1

（asm-generic：為安全計(jì)算模式 1 添加常規(guī) seccomp.h），作者：AKASHI Takahiro

21．4f12b53 add seccomp syscall for compat task

（為兼容性任務(wù)添加seccomp系統(tǒng)調(diào)用），作者：AKASHI Takahiro

22．7722723 arm64: add SIGSYS siginfo for compat task

（arm64：為兼容性任務(wù)添加 SIGSYS siginfo），作者：AKASHI Takahiro

23．210957c arm64: add seccomp support

（arm64：添加 seccomp 支持），作者：AKASHI Takahiro?

四、HWAddressSanitizer

硬件輔助的AddressSanitizer (HWASan) 是一款類似于AddressSanitizer的內(nèi)存錯(cuò)誤檢測(cè)工具。與ASan相比，HWASan使用的內(nèi)存少得多，因而更適合用于整個(gè)系統(tǒng)的清理。HWASan 僅適用于Android 10及更高版本，且只能用于AArch64硬件。具體可以檢測(cè)到以下異常情況：

• 堆棧和堆緩沖區(qū)上溢/下溢
• 釋放之后的堆使用情況
• 超出范圍的堆棧使用情況
• 重復(fù)釋放/錯(cuò)誤釋放
• 返回之后的堆棧使用情況

HWASan基于內(nèi)存標(biāo)記方法，在這種方法中，小的隨機(jī)標(biāo)記值同時(shí)與指針和內(nèi)存地址范圍相關(guān)聯(lián)。為使內(nèi)存訪問有效，指針和內(nèi)存標(biāo)記必須匹配。HWASan依賴于ARMv8功能 Top-Byte-Ignore（TBI，也稱為虛擬地址標(biāo)記）將指針標(biāo)記存儲(chǔ)在地址的最高位。

HWASan要求Linux內(nèi)核接受系統(tǒng)調(diào)用參數(shù)中被標(biāo)記的指針。在以下上游補(bǔ)丁程序集中實(shí)現(xiàn)了對(duì)此項(xiàng)要求的支持：

• arm64 已標(biāo)記地址 ABI
• arm64：對(duì)傳遞給內(nèi)核的用戶指針取消標(biāo)記
• mm：避免在 brk()/mmap()/mremap() 中創(chuàng)建虛擬地址別名
• arm64：驗(yàn)證從內(nèi)核線程調(diào)用的 access_ok() 中的已標(biāo)記地址

Android-4.14及更高分支中的通用Android內(nèi)核以向后移植的形式提供這些補(bǔ)丁程序，但 Android 10專屬分支（例如android-4.14-q）未以向后移植的形式提供這些補(bǔ)丁程序。

五、KASAN

Android包括內(nèi)核地址排錯(cuò)程序(KASAN)。KASAN是內(nèi)核與編譯時(shí)修改的組合，形成了一個(gè)插樁系統(tǒng)，可以實(shí)現(xiàn)更簡(jiǎn)單的錯(cuò)誤發(fā)現(xiàn)和根本原因分析。KASAN可以檢測(cè)內(nèi)核中許多類型的內(nèi)存違規(guī)行為。它還可以檢測(cè)堆棧、堆和全局變量中的出界讀取和寫入操作，并可檢測(cè)釋放后再使用和雙重釋放錯(cuò)誤。KASAN將編譯時(shí)內(nèi)存函數(shù)插樁與影子內(nèi)存相結(jié)合，以便跟蹤運(yùn)行時(shí)的內(nèi)存訪問，會(huì)有八分之一的內(nèi)核內(nèi)存空間專用于影子內(nèi)存，以確定內(nèi)存訪問是否有效。目前在x86_64和 arm64架構(gòu)中受支持。自4.0以來，它一直是上游內(nèi)核的一部分，并且已經(jīng)反向移植到基于Android 3.18的內(nèi)核。KASAN已在基于內(nèi)核4.9.2 通過gcc編譯的Android內(nèi)核上進(jìn)行了測(cè)試。除了KASAN，kcov是另一個(gè)對(duì)測(cè)試非常有用的內(nèi)核修改。kcov旨在允許在內(nèi)核中進(jìn)行覆蓋率引導(dǎo)模糊測(cè)試。它會(huì)測(cè)量在系統(tǒng)調(diào)用輸入方面的覆蓋率，對(duì)于模糊系統(tǒng)（如syzkaller）非常有用。如需在啟用KASAN和kcov的情況下編譯內(nèi)核，請(qǐng)將以下構(gòu)建標(biāo)志添加到內(nèi)核構(gòu)建配置：

CONFIG_KASANCONFIG_KASAN_INLINECONFIG_TEST_KASANCONFIG_KCOVCONFIG_SLUBCONFIG_SLUB_DEBUGCONFIG_CC_OPTIMIZE_FOR_SIZE并移除以下內(nèi)容：CONFIG_SLUB_DEBUG_ONCONFIG_SLUB_DEBUG_PANIC_ONCONFIG_KASAN_OUTLINECONFIG_KERNEL_LZ4然后照常構(gòu)建和刷寫內(nèi)核。KASAN內(nèi)核比原始內(nèi)核大得多?？紤]到這一點(diǎn)，請(qǐng)修改任何啟動(dòng)參數(shù)和引導(dǎo)加載程序設(shè)置（如果適用）。刷寫內(nèi)核后，檢查內(nèi)核啟動(dòng)日志，看看KASAN是否已啟用并正在運(yùn)行。內(nèi)核將啟動(dòng)并顯示KASAN的內(nèi)存映射信息，例如：

...
[    0.000000] c0      0 Virtual kernel memory layout:
[    0.000000] c0      0     kasan   : 0xffffff8000000000 - 0xffffff9000000000   (    64 GB)
[    0.000000] c0      0     vmalloc : 0xffffff9000010000 - 0xffffffbdbfff0000   (   182 GB)
[    0.000000] c0      0     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
[    0.000000] c0      0               0xffffffbdc0000000 - 0xffffffbdc3f95400   (    63 MB actual)
[    0.000000] c0      0     PCI I/O : 0xffffffbffa000000 - 0xffffffbffb000000   (    16 MB)
[    0.000000] c0      0     fixed   : 0xffffffbffbdfd000 - 0xffffffbffbdff000   (     8 KB)
[    0.000000] c0      0     modules : 0xffffffbffc000000 - 0xffffffc000000000   (    64 MB)
[    0.000000] c0      0     memory  : 0xffffffc000000000 - 0xffffffc0fe550000   (  4069 MB)
[    0.000000] c0      0       .init : 0xffffffc001d33000 - 0xffffffc001dce000   (   620 KB)
[    0.000000] c0      0       .text : 0xffffffc000080000 - 0xffffffc001d32284   ( 29385 KB)
...

錯(cuò)誤將如下所示：

[   18.539668] c3      1 ==================================================================
[   18.547662] c3      1 BUG: KASAN: null-ptr-deref on address 0000000000000008
[   18.554689] c3      1 Read of size 8 by task swapper/0/1
[   18.559988] c3      1 CPU: 3 PID: 1 Comm: swapper/0 Tainted: G        W      3.18.24-xxx #1
[   18.569275] c3      1 Hardware name: Android Device
[   18.577433] c3      1 Call trace:
[   18.580739] c3      1 [<ffffffc00008b32c>] dump_backtrace+0x0/0x2c4
[   18.586985] c3      1 [<ffffffc00008b600>] show_stack+0x10/0x1c
[   18.592889] c3      1 [<ffffffc001481194>] dump_stack+0x74/0xc8
[   18.598792] c3      1 [<ffffffc000202ee0>] kasan_report+0x11c/0x4d0
[   18.605038] c3      1 [<ffffffc00020286c>] __asan_load8+0x20/0x80
[   18.611115] c3      1 [<ffffffc000bdefe8>] android_verity_ctr+0x8cc/0x1024
[   18.617976] c3      1 [<ffffffc000bcaa2c>] dm_table_add_target+0x3dc/0x50c
[   18.624832] c3      1 [<ffffffc001bdbe60>] dm_run_setup+0x50c/0x678
[   18.631082] c3      1 [<ffffffc001bda8c0>] prepare_namespace+0x44/0x1ac
[   18.637676] c3      1 [<ffffffc001bda170>] kernel_init_freeable+0x328/0x364
[   18.644625] c3      1 [<ffffffc001478e20>] kernel_init+0x10/0xd8
[   18.650613] c3      1 ==================================================================

六、Top-byte lgnore

從Android 11開始，對(duì)于64位進(jìn)程，所有堆分配都具有一個(gè)由實(shí)現(xiàn)定義的標(biāo)記，該標(biāo)記在具有對(duì)ARM Top-byte Ignore(TBI) 的內(nèi)核支持的設(shè)備上的指針頂部字節(jié)中設(shè)置。在回收期間檢查該標(biāo)記時(shí)，任何修改此標(biāo)記的應(yīng)用都會(huì)被終止。對(duì)于未來支持ARM內(nèi)存標(biāo)記擴(kuò)展(MTE)的硬件來說，這是必需的。ARM的Top-byte Ignore功能適用于所有Armv8 AArch64硬件中的64位代碼。此功能意味著硬件在訪問內(nèi)存時(shí)會(huì)忽略指針的頂部字節(jié)。TBI需要一個(gè)兼容的內(nèi)核，以便正確處理從用戶空間傳遞的已加標(biāo)記的指針。4.14(Pixel 4) 及更高版本中的Android通用內(nèi)核具有必需的TBI補(bǔ)丁程序。在內(nèi)核中支持TBI的設(shè)備在進(jìn)程啟動(dòng)時(shí)會(huì)被動(dòng)態(tài)檢測(cè)到，并且對(duì)于所有堆分配，都會(huì)在指針頂部字節(jié)中插入一個(gè)依賴于實(shí)現(xiàn)的標(biāo)記。之后，系統(tǒng)會(huì)運(yùn)行一項(xiàng)檢查，以確保在回收內(nèi)存時(shí)，相應(yīng)標(biāo)記沒有被截?cái)?。ARM的內(nèi)存標(biāo)記擴(kuò)展(MTE)可以幫助解決內(nèi)存安全問題。MTE的工作原理是對(duì)堆棧、堆和全局變量上的每次內(nèi)存分配的第 56到59個(gè)地址位加標(biāo)記。硬件和指令集會(huì)自動(dòng)檢查每次訪問內(nèi)存時(shí)是否使用了正確的標(biāo)記。在指針頂部字節(jié)中錯(cuò)誤存儲(chǔ)信息的Android應(yīng)用一定會(huì)在啟用了MTE的設(shè)備上中斷。利用加標(biāo)記的指針，可以在MTE設(shè)備可用之前更輕松地檢測(cè)并拒絕對(duì)指針頂部字節(jié)的錯(cuò)誤使用。

七、流控完整性（CFI）

從2016年開始，Android上大約86%的漏洞與內(nèi)存安全相關(guān)。大多數(shù)漏洞被攻擊者所利用，他們會(huì)改變應(yīng)用的正?？刂屏鳎@取遭利用的應(yīng)用的所有權(quán)限來執(zhí)行任意惡意活動(dòng)?？刂屏魍暾?(CFI)是一種安全機(jī)制，它不允許更改已編譯二進(jìn)制文件的原始控制流圖，因而執(zhí)行此類攻擊變得異常困難。在Android 8.1媒體堆棧中啟用了LLVM的CFI實(shí)現(xiàn)。在Android 9中的更多組件以及內(nèi)核中啟用了CFI。系統(tǒng)CFI 默認(rèn)處于啟用狀態(tài)，但內(nèi)核CFI需要手動(dòng)啟用。LLVM的CFI需要使用鏈接時(shí)優(yōu)化(LTO)進(jìn)行編譯。LTO會(huì)一直保留對(duì)象文件的LLVM位碼表示法直至鏈接時(shí)，以便編譯器更好地推斷可以執(zhí)行哪些優(yōu)化。啟用LTO可縮減最終二進(jìn)制文件的大小并提高性能，但會(huì)增加編譯時(shí)間。在Android上進(jìn)行測(cè)試時(shí)，結(jié)合使用 LTO和CFI對(duì)代碼大小和性能開銷的影響微乎其微；在少數(shù)情況下，這兩者都會(huì)有所改善。在模塊中想打開CFI的話，makefile（如/platform/frameworks/av/cmds/stagefright/Android.mk）中需要添加以下幾行代碼：?

#在構(gòu)建過程中將CFI指定為排錯(cuò)程序
LOCAL_SANITIZE := cfi 

#開啟CFI的診斷模式。診斷模式會(huì)在崩潰期間在logcat中輸出額外的調(diào)試信息，這在開發(fā)和測(cè)試build時(shí)很有用
LOCAL_SANITIZE_DIAG := cfi

#支持組件針對(duì)個(gè)別函數(shù)或源代碼文件選擇性地停用CFI插樁
LOCAL_SANITIZE_BLACKLIST := cfi_blacklist.txt

所有受支持的Android內(nèi)核版本中都包含kCFI補(bǔ)丁，CONFIG_CFI_CLANG選項(xiàng)會(huì)啟用 kCFI，并在 GKI 中有默認(rèn)設(shè)置。啟用kCFI后，修正其驅(qū)動(dòng)程序可能存在的任何類型不匹配錯(cuò)誤。通過不兼容的函數(shù)指針間接調(diào)用函數(shù)將導(dǎo)致CFI故障。當(dāng)檢測(cè)到CFI故障時(shí)，內(nèi)核會(huì)輸出一條警告，其中包括被調(diào)用的函數(shù)和導(dǎo)致故障的堆棧軌跡?？梢酝ㄟ^確保函數(shù)指針始終與調(diào)用的函數(shù)屬于同一類型來修正此問題。如需協(xié)助調(diào)試CFI故障，請(qǐng)啟用CONFIG_CFI_PERMISSIVE，它會(huì)輸出警告（而不會(huì)導(dǎo)致內(nèi)核崩潰）。

八、ShadowCallStack

ShadowCallStack(SCS)是一種LLVM插樁模式，可將函數(shù)的返回地址保存到非葉函數(shù)的函數(shù)prolog中單獨(dú)分配的ShadowCallStack，并從函數(shù)epilog中的ShadowCallStack加載返回地址，從而防止返回地址覆蓋（比如堆棧緩沖區(qū)溢出）。返回地址也存儲(chǔ)在常規(guī)堆棧中，以便與展開程序兼容，但除此之外就沒有用處。這樣可以確保攻擊行為（修改常規(guī)堆棧上的返回地址）不會(huì)對(duì)程序控制流造成任何影響。在aarch64上，此插樁機(jī)制使用x18寄存器來引用ShadowCallStack，這意味著不必將對(duì) ShadowCallStack的引用存儲(chǔ)在內(nèi)存中。因此，實(shí)現(xiàn)的運(yùn)行時(shí)可避免將ShadowCallStack地址暴露給能夠讀取任意內(nèi)存的攻擊者 。要為內(nèi)核啟用ShadowCallStack，請(qǐng)將下面這行代碼添加到內(nèi)核配置文件:

CONFIG_SHADOW_CALL_STACK=y

九、總結(jié)

除以上內(nèi)核安全特性外，Android提供了一些關(guān)鍵的安全功能，其中包括：

• 基于用戶的權(quán)限模式
• 進(jìn)程隔離
• 實(shí)現(xiàn)安全I(xiàn)PC的可擴(kuò)展機(jī)制

移除內(nèi)核中不必要的和可能不安全的部分

我們也可以看到，上述很多功能都是基于LLVM編譯器來實(shí)現(xiàn)，在現(xiàn)實(shí)工作中，LLVM也不只是作為一個(gè)Compiler使用，對(duì)于優(yōu)化程序性能、增加安全檢測(cè)等更是有很大的幫助，包括safe stack、CFI、LeakSanitizer、MemorySanitizer等等方案，隨著Android的演進(jìn)，Android內(nèi)核在集成Linux內(nèi)核主線版本的優(yōu)勢(shì)下，再發(fā)展適合自身生態(tài)的內(nèi)核安全方案，在龐大數(shù)量設(shè)備的基礎(chǔ)上，既是挑戰(zhàn)，也是機(jī)遇，期待Android能給出完美的答案。

作者簡(jiǎn)介：

許慶偉：龍蜥社區(qū)eBPF技術(shù)探索SIG組 Maintainer & Linux Kernel Security Researcher