一、知識背景 隨著2003年10月安迪魯賓聯合幾位朋友創建了Android公司，后來影響眾人的智能設備操作系統公司由此而生（2005年被Google收購）?，F如今，世界上越來越多的智能終端包括手機、TV、SmartBox和IoT、汽車、多媒體設備等等，均深度使用Android系統，而Android的底層正是Linux內核，這也讓Linux內核的安全性對Android產生重大影響。 但由于Android由于想繞過商業授權的問題，又研究出來了以bionic取代Glibc、以Skia取代Cairo等類似的方案，使用的不是標準內核和GNU/Linux。由于這些原因，Google在Android內核開源的問題上，理念和Linux內核社區不是十分的匹配，這也導致了Android對內核做了大量的針對性修改，但是無法合入到Upstream上。這也導致了Android內核在安全側有部分不同于Linux內核，側重點也存在不同。

在操作系統級別，Android平臺不僅提供Linux內核的安全功能，而且還提供安全的進程間通信 (IPC)機制，以便在不同進程中運行的應用之間安全通信。操作系統級別的這些安全功能旨在確保即使是原生代碼也要受應用沙盒的限制。無論相應代碼是自帶應用行為導致的結果，還是利用應用漏洞導致的結果，系統都能防止違規應用危害其他應用、Android 系統或設備本身。 以下配置設置用作Android 內核配置的基礎。設置會整理android-base和android- recommended.cfg 文件，android-base.cfg 和 android-recommended.cfg 文件均位于 android-common內核repo：https://android.googlesource.com/kernel/common/。

android-base這些選項可實現核心Android功能，所有設備都應該啟用。

android-recommended這些選項可實現高級Android功能，設備可選擇性啟用。

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

二、生成內核配置 對于具有極簡defconfig的設備，您可以使用以下命令來啟用選項,生成一個.config文件，使用該文件來保存新的defconfig或編譯一個啟用Android功能的新內核：
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是一種內核安全技術，支持創建沙盒來限制進程可以進行的系統調用。TSYNC功能可以實現從多線程程序中使用Seccomp-BPF。這種能力僅限具有seccomp支持上游的架構：ARM、ARM64、x86 和 x86_64。 用于ARM-32、X86、X86_64的內核3.10向后移植,確保Kconfig中已啟用CONFIG_SECCOMP_FILTER=y（截至Android 5.0 CTS已驗證），然后擇優挑選來自AOSP kernel/common:android-3.10存儲區的以下變更：9499cd23f9d05ba159fac6d55dc35a7f49f9ce76…a9ba4285aa5722a3b4d84888e78ba8adc0046b28 1．cfc7e99e9 arm64: Add _NR* definitions for compat syscalls
（arm64：為兼容性系統調用添加 _NR* 定義），作者：JP Abgrall
2．bf11863 arm64: Add audit support
（arm64：添加審計支持），作者：AKASHI Takahiro
3．3e21c0b arm64: audit: Add audit hook in syscall_trace_enter/exit()
（arm64：審計：在 syscall_trace_enter/exit() 中添加審計鉤），作者：JP Abgrall
4．9499cd2 syscall_get_arch: remove useless function arguments
（syscall_get_arch：移除無用的函數參數），作者：Eric Paris
5．2a30a43 seccomp: create internal mode-setting function
（seccomp：創建內部 mode-setting函數），作者：Kees Cook
6．b8a9cff seccomp: extract check/assign mode helpers
（seccomp：提取檢查/分配模式幫助程序），作者：Kees Cook
7．8908dde seccomp: split mode setting routines
（seccomp：拆分模式設置例行程序），作者：Kees Cook
8．e985fd4 seccomp: add “seccomp” syscall
（seccomp：添加“seccomp”系統調用），作者：Kees Cook
9．9d0ff69 sched: move no_new_privs into new atomic flags
（sched：將 no_new_privs 移至新的原子標志中），作者：Kees Cook
10．b6a12bf seccomp: split filter prep from check and apply
（seccomp：將過濾器準備工作從檢查和應用流程中分離出來），作者：Kees Cook
11．61b6b88 seccomp: introduce writer locking
（seccomp：引入寫入者鎖定），作者：Kees Cook
12．c852ef7 seccomp: allow mode setting across threads
（seccomp：允許跨線程模式設置），作者：Kees Cook
13．f14a5db seccomp: implement SECCOMP_FILTER_FLAG_TSYNC
（seccomp：實施 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：修復 x86 和 x86_64 的系統調用號），作者：Lee Campbell
16．a9ba428 ARM: add seccomp syscall
（ARM：添加 seccomp 系統調用），作者：Kees Cook
17．4190090 ARM: 8087/1: ptrace: reload syscall number after secure_computing() check
（ARM：8087/1：ptrace：在 secure_computing() 檢查后重新加載系統調用號），作者：Will Deacon
18．abbfed9 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：允許跟蹤進程跳過系統調用），作者：AKASHI Takahiro
20．dab1073 asm-generic: add generic seccomp.h for secure computing mode 1
（asm-generic：為安全計算模式 1 添加常規 seccomp.h），作者：AKASHI Takahiro
21．4f12b53 add seccomp syscall for compat task
（為兼容性任務添加seccomp系統調用），作者：AKASHI Takahiro
22．7722723 arm64: add SIGSYS siginfo for compat task
（arm64：為兼容性任務添加 SIGSYS siginfo），作者：AKASHI Takahiro
23．210957c arm64: add seccomp support
（arm64：添加 seccomp 支持），作者：AKASHI Takahiro

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

堆棧和堆緩沖區上溢/下溢

釋放之后的堆使用情況

超出范圍的堆棧使用情況

重復釋放/錯誤釋放

返回之后的堆棧使用情況

HWASan基于內存標記方法，在這種方法中，小的隨機標記值同時與指針和內存地址范圍相關聯。為使內存訪問有效，指針和內存標記必須匹配。HWASan依賴于ARMv8功能 Top-Byte-Ignore（TBI，也稱為虛擬地址標記）將指針標記存儲在地址的最高位。 HWASan要求Linux內核接受系統調用參數中被標記的指針。在以下上游補丁程序集中實現了對此項要求的支持：

arm64 已標記地址 ABI

arm64：對傳遞給內核的用戶指針取消標記

mm：避免在 brk()/mmap()/mremap() 中創建虛擬地址別名

arm64：驗證從內核線程調用的 access_ok() 中的已標記地址

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

五、KASAN Android包括內核地址排錯程序(KASAN)。KASAN是內核與編譯時修改的組合，形成了一個插樁系統，可以實現更簡單的錯誤發現和根本原因分析。KASAN可以檢測內核中許多類型的內存違規行為。它還可以檢測堆棧、堆和全局變量中的出界讀取和寫入操作，并可檢測釋放后再使用和雙重釋放錯誤。 KASAN將編譯時內存函數插樁與影子內存相結合，以便跟蹤運行時的內存訪問，會有八分之一的內核內存空間專用于影子內存，以確定內存訪問是否有效。目前在x86_64和 arm64架構中受支持。自4.0以來，它一直是上游內核的一部分，并且已經反向移植到基于Android 3.18的內核。KASAN已在基于內核4.9.2 通過gcc編譯的Android內核上進行了測試。 除了KASAN，kcov是另一個對測試非常有用的內核修改。kcov旨在允許在內核中進行覆蓋率引導模糊測試。它會測量在系統調用輸入方面的覆蓋率，對于模糊系統（如syzkaller）非常有用。 如需在啟用KASAN和kcov的情況下編譯內核，請將以下構建標志添加到內核構建配置：
CONFIG_KASAN
CONFIG_KASAN_INLINE
CONFIG_TEST_KASAN
CONFIG_KCOV
CONFIG_SLUB
CONFIG_SLUB_DEBUG
CONFIG_CC_OPTIMIZE_FOR_SIZE
并移除以下內容：
CONFIG_SLUB_DEBUG_ON
CONFIG_SLUB_DEBUG_PANIC_ON
CONFIG_KASAN_OUTLINE
CONFIG_KERNEL_LZ4 然后照常構建和刷寫內核。KASAN內核比原始內核大得多?？紤]到這一點，請修改任何啟動參數和引導加載程序設置（如果適用）。 刷寫內核后，檢查內核啟動日志，看看KASAN是否已啟用并正在運行。內核將啟動并顯示KASAN的內存映射信息，例如：

...[    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)...

錯誤將如下所示：

[   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 [] dump_backtrace+0x0/0x2c4[   18.586985] c3      1 [] show_stack+0x10/0x1c[   18.592889] c3      1 [] dump_stack+0x74/0xc8[   18.598792] c3      1 [] kasan_report+0x11c/0x4d0[   18.605038] c3      1 [] __asan_load8+0x20/0x80[   18.611115] c3      1 [] android_verity_ctr+0x8cc/0x1024[   18.617976] c3      1 [] dm_table_add_target+0x3dc/0x50c[   18.624832] c3      1 [] dm_run_setup+0x50c/0x678[   18.631082] c3      1 [] prepare_namespace+0x44/0x1ac[   18.637676] c3      1 [] kernel_init_freeable+0x328/0x364[   18.644625] c3      1 [] kernel_init+0x10/0xd8[18.650613]c31==================================================================

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

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

#在構建過程中將CFI指定為排錯程序LOCAL_SANITIZE:=cfi

#開啟CFI的診斷模式。診斷模式會在崩潰期間在logcat中輸出額外的調試信息，這在開發和測試build時很有用LOCAL_SANITIZE_DIAG:=cfi

#支持組件針對個別函數或源代碼文件選擇性地停用CFI插樁LOCAL_SANITIZE_BLACKLIST:=cfi_blacklist.txt

所有受支持的Android內核版本中都包含kCFI補丁，CONFIG_CFI_CLANG選項會啟用 kCFI，并在 GKI 中有默認設置。 啟用kCFI后，修正其驅動程序可能存在的任何類型不匹配錯誤。通過不兼容的函數指針間接調用函數將導致CFI故障。當檢測到CFI故障時，內核會輸出一條警告，其中包括被調用的函數和導致故障的堆棧軌跡。可以通過確保函數指針始終與調用的函數屬于同一類型來修正此問題。 如需協助調試CFI故障，請啟用CONFIG_CFI_PERMISSIVE，它會輸出警告（而不會導致內核崩潰）。

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

CONFIG_SHADOW_CALL_STACK=y

九、總結 除以上內核安全特性外，Android提供了一些關鍵的安全功能，其中包括： 基于用戶的權限模式