Linux内核的安全性对Android的影响-德赢Vwin官网网

一、知识背景 随着2003年10月安迪鲁宾联合几位朋友创建了Android 公司，后来影响众人的智能设备操作系统公司由此而生（2005年被Google收购）。现如今，世界上越来越多的智能终端包括手机、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提供了一些关键的安全功能，其中包括：基于用户的权限模式

审核编辑：彭静

声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表德赢Vwin官网网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。举报投诉

Android

Android

+关注

关注
12

文章
3935

浏览量
127333
程序

程序

+关注

关注
117

文章
3785

浏览量
80999
LINUX内核

LINUX内核

+关注

关注
1

文章
316

浏览量
21644

原文标题：分歧还是共存？详解Android内核安全

文章出处：【微信号：LinuxDev，微信公众号：Linux阅码场】欢迎添加关注！文章转载请注明出处。

视频安全性好处

视频安全性好处

发表于 09-26 18:43

μC/OSII安全性与稳定性怎么提高？

μC/OSII是基于优先级的可剥夺型内核，系统中的所有任务都有一个唯一的优先级别，它适合应用在实时性要求较强的场合；但是它不区分用户空间和系统空间，使系统的安全性变差。而移植到CortexM3内核上

发表于 11-01 06:18

你的应用程序如何保持安全性？

引言拥有特权的恶意软件或者可以实际访问安卓设备的攻击者是一个难以防范的攻击向量。在这种情况下，你的应用程序如何保持安全性？本文将讨论 Android keystore 机制以及在尝试实现安全

发表于 07-28 08:40

数据库安全性概述

本文主讲数据库的安全性，欢迎阅读~????目录一、数据库安全性概述二、数据库安全性控制1. 用户标识与鉴别2. 存取控制3. 自主存取控制方法4. 授权与回收5. 数据库角色6. 强制存取控制方法

发表于 07-30 06:42

关于 eBPF 安全可观测性，你需要知道的那些事儿

Android 的底层正是 Linux 内核，这也让 Linux 内核的安全性对

发表于 09-08 15:31

linux操作系统的安全性

linux操作系统的安全性 计算机系统安全性的内涵操作系统的安全性功能操作系统的安全机制安

发表于 04-28 15:05 •0次下载

Android内核分析

介绍Android 移动平台系统架构，通过对Android 源代码的分析，将其与标准Linux 内核（2.6.27）源代码相比较，详细解析Andro

发表于 10-29 16:17 •116次下载

Android的Linux内核与驱动程序开发教程

Android内核是基于Linux 2.6内核的,它是一个增强内核版本，除了修改部分Bug外，它提供了用于支持

发表于 09-05 14:24 •335次下载

Linux内核与Android的关系

Android虽然建立在Linux内核之上，但是他对内核进行了一些扩展，增加了一些驱动。比如Binder，loger等等驱动。可以拿Android

发表于 09-09 09:10 •4586次阅读

基于Android的Linux内核的电源管理

Early Suspend和Late Resume是Android在标准Linux的基础上增加的一项特性。当用户空间的向内核请求进入suspend时，这时候会先进入early suspend状态，驱动程序可以注册early su

发表于 04-24 13:47 •1072次阅读

谷歌Android设备内核引入主线Linux内核难吗？

Android是基于Linux内核的操作系统，但是，运行在Android设备上的内核其实与Google选择的LTS版本

发表于 11-22 10:41 •3051次阅读

Linux的安全性分析说明

很多人看到系统修复模式这节内容时，都会有所感慨：Linux的密码破解太容易了，这样的操作系统还安全吗？Linux不是以安全性著称的吗？

发表于 07-14 14:17 •862次阅读

如何尽可能地加强Linux的安全性和隐私性？

本指南旨在说明如何尽可能地加强Linux的安全性和隐私性，并且不限于任何特定的指南。免责声明：如果您不确定自己在做什么，请不要尝试在本文中使用任何内容。本指南仅关注安全性和隐私

发表于 04-25 14:58 •2414次阅读

谷歌Rust的加入能提高Linux内核安全性

声音就更多了。不过近日谷歌用行动表示，它并没有忘记 Android 和 Chrome OS 这两个“儿子”：为提高未来 Android 和 Chrome OS的安全性，谷歌正在资助一个使 Rust 进驻

发表于 06-24 15:51 •1651次阅读

设计LSM钩子提升Linux漏洞安全性

Tracee是一个用于Linux的运行时安全性和取证的开源项目，用于解决常见的Linux安全性问题。

发表于 07-11 10:55 •934次阅读