android HAL层崩溃排查记录
要最近在调试系统HDMI CEC功能时，遇到一个奇怪的崩溃问题，这边记录下。
初步分析
先上日志：
--------- beginning of crash
03-06 10:48:25.503 1133 1133 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-06 10:48:25.503 1133 1133 F DEBUG : Build fingerprint: ':13/TD1A.220804.031/3582:userdebug/release-keys'
03-06 10:48:25.503 1133 1133 F DEBUG : Revision: '0'
03-06 10:48:25.503 1133 1133 F DEBUG : ABI: 'arm64'
03-06 10:48:25.503 1133 1133 F DEBUG : Timestamp: 2024-03-06 10:48:25.490260378-0500
03-06 10:48:25.503 1133 1133 F DEBUG : Process uptime: 6s
03-06 10:48:25.503 1133 1133 F DEBUG : Cmdline: /vendor/bin/hw/android.hardware.tv.cec@1.0-service
03-06 10:48:25.503 1133 1133 F DEBUG : pid: 615, tid: 615, name: cec@1.0-service >>> /vendor/bin/hw/android.hardware.tv.cec@1.0-service <<<
03-06 10:48:25.503 1133 1133 F DEBUG : uid: 1000
03-06 10:48:25.503 1133 1133 F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
03-06 10:48:25.503 1133 1133 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
03-06 10:48:25.503 1133 1133 F DEBUG : Abort message: 'stack corruption detected (-fstack-protector)'
03-06 10:48:25.503 1133 1133 F DEBUG : x0 0000000000000000 x1 0000000000000267 x2 0000000000000006 x3 0000007fe8d61420
03-06 10:48:25.503 1133 1133 F DEBUG : x4 0000000000808080 x5 0000000000808080 x6 0000000000808080 x7 8080808080808080
03-06 10:48:25.503 1133 1133 F DEBUG : x8 00000000000000f0 x9 00000077cc5b4a00 x10 0000000000000001 x11 00000077cc5f2ce4
03-06 10:48:25.503 1133 1133 F DEBUG : x12 0101010101010101 x13 000000007fffffff x14 0000000000001686 x15 0000000000000030
03-06 10:48:25.503 1133 1133 F DEBUG : x16 00000077cc657d60 x17 00000077cc634b70 x18 00000077d3ae2000 x19 0000000000000267
03-06 10:48:25.504 1133 1133 F DEBUG : x20 0000000000000267 x21 00000000ffffffff x22 0000000000000030 x23 00000077d302a000
03-06 10:48:25.504 1133 1133 F DEBUG : x24 0000000000000004 x25 00000077d302a000 x26 00000077d302a000 x27 b40000763c5972c8
03-06 10:48:25.504 1133 1133 F DEBUG : x28 0000000000000000 x29 0000007fe8d614a0
03-06 10:48:25.504 1133 1133 F DEBUG : lr 00000077cc5e4868 sp 0000007fe8d61400 pc 00000077cc5e4894 pst 0000000000001000
03-06 10:48:25.504 1133 1133 F DEBUG : backtrace:
03-06 10:48:25.504 1133 1133 F DEBUG : #00 pc 0000000000051894 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
03-06 10:48:25.504 1133 1133 F DEBUG : #01 pc 00000000000664e8 /apex/com.android.runtime/lib64/bionic/libc.so (__stack_chk_fail+20) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
03-06 10:48:25.504 1133 1133 F DEBUG : #02 pc 0000000000006954 /vendor/lib64/hw/android.hardware.tv.cec@1.0-impl.so (android::hardware::tv::cec::V1_0::implementation::HdmiCec::getPortInfo(std::__1::function<void (android::hardware::hidl_vec<android::hardware::tv::cec::V1_0::HdmiPortInfo> const&)>)+376) (BuildId: 647cc2659b38df33f681ae1d58a04c74)
03-06 10:48:25.504 1133 1133 F DEBUG : #03 pc 0000000000016540 /vendor/lib64/android.hardware.tv.cec@1.0.so (android::hardware::tv::cec::V1_0::BnHwHdmiCec::_hidl_getPortInfo(android::hidl::base::V1_0::BnHwBase*, android::hardware::Parcel const&, android::hardware::Parcel*, std::__1::function<void (android::hardware::Parcel&)>)+252) (BuildId: 8ca54579dc40d30a62824bb0a91d98f4)
03-06 10:48:25.504 1133 1133 F DEBUG : #04 pc 0000000000017668 /vendor/lib64/android.hardware.tv.cec@1.0.so (android::hardware::tv::cec::V1_0::BnHwHdmiCec::onTransact(unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int, std::__1::function<void (android::hardware::Parcel&)>)+1132) (BuildId: 8ca54579dc40d30a62824bb0a91d98f4)
03-06 10:48:25.504 1133 1133 F DEBUG : #05 pc 000000000008ee40 /apex/com.android.vndk.v33/lib64/libhidlbase.so (android::hardware::BHwBinder::transact(unsigned int, android::hardware::Parcel const&, android::hardware::Parcel*, unsigned int, std::__1::function<void (android::hardware::Parcel&)>)+156) (BuildId: 3fafcf3a9734f0d41045c2b5f828b363)
03-06 10:48:25.504 1133 1133 F DEBUG : #06 pc 0000000000093dfc /apex/com.android.vndk.v33/lib64/libhidlbase.so (android::hardware::IPCThreadState::executeCommand(int)+2784) (BuildId: 3fafcf3a9734f0d41045c2b5f828b363)
03-06 10:48:25.504 1133 1133 F DEBUG : #07 pc 00000000000931bc /apex/com.android.vndk.v33/lib64/libhidlbase.so (android::hardware::IPCThreadState::getAndExecuteCommand()+224) (BuildId: 3fafcf3a9734f0d41045c2b5f828b363)
03-06 10:48:25.504 1133 1133 F DEBUG : #08 pc 0000000000094388 /apex/com.android.vndk.v33/lib64/libhidlbase.so (android::hardware::IPCThreadState::joinThreadPool(bool)+172) (BuildId: 3fafcf3a9734f0d41045c2b5f828b363)
03-06 10:48:25.504 1133 1133 F DEBUG : #09 pc 00000000000010e4 /vendor/bin/hw/android.hardware.tv.cec@1.0-service (main+144) (BuildId: f6a65dc725b06643501c269fa219b717)
03-06 10:48:25.504 1133 1133 F DEBUG : #10 pc 000000000004a0f4 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 058e3ec96fa600fb840a6a6956c6b64e)
03-06 10:48:26.344 1267 1267 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***初步看了下，崩溃在android.hardware.tv.cec@1.0-service 服务进程中。那么简单，上addr2line工具。
addr2line
addr2line --help
Usage: addr2line [option(s)] [addr(s)]
Convert addresses into line number/file name pairs.
If no addresses are specified on the command line, they will be read from stdin
The options are:
@<file> Read options from <file>
-a --addresses Show addresses
-b --target=<bfdname> Set the binary file format
-e --exe=<executable> Set the input file name (default is a.out)
-i --inlines Unwind inlined functions
-j --section=<name> Read section-relative offsets instead of addresses
-p --pretty-print Make the output easier to read for humans
-s --basenames Strip directory names
-f --functions Show function names
-C --demangle[=style] Demangle function names
-R --recurse-limit Enable a limit on recursion whilst demangling. [Default]
-r --no-recurse-limit Disable a limit on recursion whilst demangling
-h --help Display this information
-v --version Display the program's version
addr2line: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pe-x86-64 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex binary ihex plugin
Report bugs to <https://sourceware.org/bugzilla/>
addr2line -ife out/target/product/aosp/symbols/vendor/lib64/hw/android.hardware.tv.cec@1.0-impl.so 0000000000006954
llvm-addr2line
记得android编译链接工具更新了，确实不能用这个版本了。下面切成llvm-addr2line工具。
prebuilts/clang/host/linux-x86/llvm-binutils-stable/llvm-addr2line --help
OVERVIEW: llvm-addr2line
USAGE: llvm-addr2line [options] addresses...
OPTIONS:
--addresses Show address before line information
--adjust-vma=<offset> Add specified offset to object file addresses
-a Alias for --addresses
--basenames Strip directory names from paths
-C Alias for --demangle
--debug-file-directory=<dir>
Path to directory where to look for debug files
-demangle=false Alias for --no-demangle
-demangle=true Alias for --demangle
--demangle Demangle function names
--dia Use the DIA library to access symbols (Windows only)
--dwp=<file> Path to DWP file to be use for any split CUs
-e=<file> Alias for --obj
--exe=<file> Alias for --obj
--exe <file> Alias for --obj
-e <file> Alias for --obj
-f=<value> Alias for --functions=
--fallback-debug-path=<dir>
Fallback path for debug binaries
--functions=<value> Print function name for a given address
--functions Print function name for a given address
-f Alias for --functions
--help Display this help
--inlines Print all inlined frames for a given address
--inlining=false Alias for --no-inlines
--inlining=true Alias for --inlines
--inlining Alias for --inlines
-i Alias for --inlines
--no-demangle Don't demangle function names
--no-inlines Do not print inlined frames
--no-untag-addresses Remove memory tags from addresses before symbolization
--obj=<file> Path to object file to be symbolized (if not provided, object file should be specified for each input line)
--output-style=style Specify print style. Supported styles: LLVM, GNU, JSON
--pretty-print Make the output more human friendly
--print-address Alias for --addresses
--print-source-context-lines=<value>
Print N lines of source file context
-p Alias for --pretty-print
--relative-address Interpret addresses as addresses relative to the image base
--relativenames Strip the compilation directory from paths
-s Alias for --basenames
--verbose Print verbose line info
--version Display the version
-v Alias for --version
llvm-symbolizer Mach-O Specific Options:
--default-arch=<value> Default architecture (for multi-arch objects)
--dsym-hint=<dir> Path to .dSYM bundles to search for debug info for the object files
Pass @FILE as argument to read options from FILE.
于是，定位命令行切换成：
prebuilts/clang/host/linux-x86/llvm-binutils-stable/llvm-addr2line -ife out/target/product/aosp/symbols/vendor/lib64/hw/android.hardware.tv.cec@1.0-impl.so 0000000000006954
_ZN7android8hardware2tv3cec4V1_014implementation7HdmiCec11getPortInfoENSt3__18functionIFvRKNS0_8hidl_vecINS3_12HdmiPortInfoEEEEEE
hardware/interfaces/tv/cec/1.0/default/HdmiCec.cpp:0怎么可能是源码的0行，现在轮到我崩溃了。。
背景知识
看来直接通过上面的通用方式，不能直接定位到崩溃点的代码了。
那从进程名，打印出来的函数名：getPortInfo ，对应的崩溃错误：
Abort message: 'stack corruption detected (-fstack-protector)'来看看能不能发现些什么。
-fstack-protector 检测到的堆栈损坏
编译器的 -fstack-protector 选项会在具有栈上缓冲区的函数中插入检查机制，以防止缓冲区溢出。默认情况下，系统会为平台代码（而非应用）启用此选项。启用此选项后，编译器会向函数序言添加指令，以在堆栈上写入刚刚超过上一局部值的随机值，并向函数结尾添加指令以进行回读并确认是否发生更改。如果该值已更改，则表示该值已被缓冲区溢出覆盖，因此该结尾会调用 __stack_chk_fail 来记录消息和中止。
pid: 26717, tid: 26717, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
r0 00000000 r1 0000685d r2 00000006 r3 00000008
r4 ffd516d8 r5 0000685d r6 0000685d r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ffd518bc
ip 00000000 sp ffd516c8 lr ee63ece3 pc ee66ef0c cpsr 000e0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e07d /system/lib/libc.so (__libc_fatal+24)
#03 pc 0004863f /system/lib/libc.so (__stack_chk_fail+6)
#04 pc 000013ed /system/xbin/crasher (smash_stack+76)
#05 pc 00001591 /system/xbin/crasher (do_action+280)
#06 pc 00002219 /system/xbin/crasher (main+100)
#07 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#08 pc 00001144 /system/xbin/crasher (_start+96)
0x00 概述
栈溢出保护是一种缓冲区溢出攻击缓解手段，当函数存在缓冲区溢出攻击漏洞时，攻击者可以覆盖栈上的返回地址来让shellcode能够得到执行。当启用栈保护后，函数开始执行的时候会先往栈里插入cookie信息，当函数真正返回的时候会验证cookie信息能否合法，假如不合法就中止程序运行。攻击者在覆盖返回地址的时候往往也会将cookie信息给覆盖掉，导致栈保护检查失败而阻止shellcode的执行。在Linux中我们将cookie信息称为canary(以下统一使用canary)。
gcc在4.2版本中增加了-fstack-protector和-fstack-protector-all编译参数以支持栈保护功能，4.9新添加了-fstack-protector-strong编译参数让保护的范围更广。以下是-fstack-protector和-fstack-protector-strong的区别：
Linux系统中存在着三种类型的栈：
-
应用程序栈：工作在Ring3,由应用程序来维护；
-
内核进程上下文栈：工作在Ring0，由内核在创立线程的时候创立；
-
内核中断上下文栈：工作在Ring0，在内核初始化的时候给每个CPU核心创立一个。
看来，是哪里可能存在内存溢出。联系到用户之前在未进行多个hdmi cec端口配置时，未有发现此问题。配置多个口后，出现此问题。而 java层代码一致，有变动的，就是HAL层这块了。
定位改动
因为有比较明确的改动地方引起，就从改动开始排查吧。
HAL被调用的地方，也是上面崩溃指向的函数：
Return<void> HdmiCec::getPortInfo(getPortInfo_cb _hidl_cb) {
struct hdmi_port_info* legacyPorts;
int numPorts;
hidl_vec<HdmiPortInfo> portInfos;
mDevice->get_port_info(mDevice, &legacyPorts, &numPorts);
portInfos.resize(numPorts);
for (int i = 0; i < numPorts; ++i) {
portInfos[i] = {
.type = static_cast<HdmiPortType>(legacyPorts[i].type),
.portId = static_cast<uint32_t>(legacyPorts[i].port_id),
.cecSupported = legacyPorts[i].cec_supported != 0,
.arcSupported = legacyPorts[i].arc_supported != 0,
.physicalAddress = legacyPorts[i].physical_address
};
}
_hidl_cb(portInfos);
return Void();
}
初始版本
struct hdmi_cec_context_t {
hdmi_cec_device_t device;
/* our private state goes below here */
event_callback_t event_callback;
void* cec_arg;
struct hdmi_port_info port;
int fd;
int en_mask;
bool enable;
bool system_control;
int phy_addr;
bool hotplug;
bool cec_init;
};
static void hdmi_cec_get_port_info(const struct hdmi_cec_device* dev,
struct hdmi_port_info* list[], int* total)
{
...
list[0] = &ctx->port;
list[0]->type = HDMI_OUTPUT;
list[0]->port_id = HDMI_CEC_PORT_ID;
list[0]->cec_supported = support;
list[0]->arc_supported = 0;
list[0]->physical_address = val;
*total = 1;
}
问题版本
struct hdmi_cec_context_t {
hdmi_cec_device_t device;
/* our private state goes below here */
event_callback_t event_callback;
void* cec_arg;
struct hdmi_port_info port[4];
int fd;
int en_mask;
bool enable;
bool system_control;
int phy_addr;
bool hotplug;
bool cec_init;
};static void hdmi_cec_get_port_info(const struct hdmi_cec_device* dev,
struct hdmi_port_info* list[], int* total)
{
...
list[0] = &ctx->port[0];
list[0]->type = HDMI_INPUT;
list[0]->port_id = 1;
list[0]->cec_supported = support;
list[0]->arc_supported = 0;
list[0]->physical_address = 0x1000;//CVT_DEF_ARC_PHYSICAL_ADDRESS;
list[1] = &ctx->port[1];
list[1]->type = HDMI_INPUT;
list[1]->port_id = 2;
list[1]->cec_supported = support;
list[1]->arc_supported = 0;
list[1]->physical_address = 0x3000;
list[2] = &ctx->port[2];
list[2]->type = HDMI_INPUT;
list[2]->port_id = 3;
list[2]->cec_supported = support;
list[2]->arc_supported = 0;
list[2]->physical_address = 0x4000;
list[3] = &ctx->port[3];
list[3]->type = HDMI_INPUT;
list[3]->port_id = 4;
list[3]->cec_supported = support;
list[3]->arc_supported = 1;
list[3]->physical_address = 0x2000;
*total = 4;
}上面测试过，只添加2个（list[0],list[1]），也是不会崩溃。看起来，是个内存溢出的问题。排查了相关数量定义，限制，似乎是没有找到有限制2个的。反馈还出现过一次配置3个的可以。
关注下面变量的定义及传递：
struct hdmi_port_info* legacyPorts;
mDevice->get_port_info(mDevice, &legacyPorts, &numPorts);
hdmi_cec_get_port_info的参数
struct hdmi_port_info* list[] 是一个指针数组，其中每个元素都是指向 struct hdmi_port_info 结构体的指针。list 是一个指针数组，它可以存储 struct hdmi_port_info* 类型的指针。
修正版本
static void hdmi_cec_get_port_info(const struct hdmi_cec_device* dev,
struct hdmi_port_info* list[], int* total)
{
...
ctx->port[0].type = HDMI_INPUT;
ctx->port[0].port_id = 1;
ctx->port[0].cec_supported = 1;
ctx->port[0].arc_supported = 1;
ctx->port[0].physical_address = 0x1000;
ctx->port[1].type = HDMI_INPUT;
ctx->port[1].port_id = 2;
ctx->port[1].cec_supported = 1;
ctx->port[1].arc_supported = 0;
ctx->port[1].physical_address = 0x2000;
ctx->port[2].type = HDMI_INPUT;
ctx->port[2].port_id = 3;
ctx->port[2].cec_supported = 1;
ctx->port[2].arc_supported = 0;
ctx->port[2].physical_address = 0x3000;
ctx->port[3].type = HDMI_INPUT;
ctx->port[3].port_id = 4;
ctx->port[3].cec_supported = 1;
ctx->port[3].arc_supported = 0;
ctx->port[3].physical_address = 0x4000;
*list = &ctx->port[0];
*total = 4;
}问题分析
让我们逐步解释上述过程中涉及到的相关步骤：
1. 定义 `legacyPorts` 指针：
struct hdmi_port_info* legacyPorts;
这行代码定义了一个名为 `legacyPorts` 的指针，它的类型是 `struct hdmi_port_info*`，即指向 `struct hdmi_port_info` 结构体的指针。
2. 调用 hdmi_cec_get_port_info 函数：
hdmi_cec_get_port_info(mDevice, &legacyPorts, &numPorts);
在这行代码中，我们将 `legacyPorts` 的地址（即指向 `legacyPorts` 指针的指针）和 `numPorts` 的地址（即指向 `numPorts` 变量的指针）传递给 `hdmi_cec_get_port_info` 函数。
3. 在 `hdmi_cec_get_port_info` 函数中：*list = ctx->port;
在函数实现中，`list` 是一个指向指针数组的指针，`ctx->port` 是指向 `struct hdmi_port_info` 数组的指针。
通过 `*list = ctx->port;` 这行代码，我们将 `ctx->port` 数组的起始地址赋值给了 `list` 指针，这样 `list` 指针就指向了 `ctx->port` 数组的内容。
由于 `legacyPorts` 是 `list` 的地址，所以在函数调用结束后，`legacyPorts` 指向了 `ctx->port` 数组的内容。
总结起来，通过使用 `&legacyPorts` 将 `legacyPorts` 的地址传递给 `hdmi_cec_get_port_info` 函数，在函数内部将 `ctx->port` 的地址赋值给了 `*list`，从而使得 `legacyPorts` 指向了 `ctx->port` 数组的内容。这样，通过 `legacyPorts` 指针，我们可以在函数外部访问和操作 `ctx->port` 数组的填充后的端口信息。
总结
所以，通过修正版本的分析，就知道问题版本出问题的原因了。
在用问题版本中，我们使用list[0] = &ctx->port[0]，对struct hdmi_port_info* list[]中的每个元素进行赋值。
list[0] = &ctx->port[0];
...
list[3]->physical_address = 0x2000;我们在调用时，定义了一个名为 `legacyPorts` 的指针，它的类型是 `struct hdmi_port_info*`，即指向 `struct hdmi_port_info` 结构体的指针。
参考链接：