Android goldfish 内核 IOCTL 系统调用 hook 内核崩溃

Question

我修改了一些系统调用。除了“ioctl”，它们都运行良好。当我尝试在我的内核模块上“rmmod”时，我看到内核 panic 。我在 android 模拟器中使用 android-goldfish-3.4 内核。

使用自定义内核运行模拟器:

emulator @nexus4 -kernel goldfish/arch/arm/boot/zImage -wipe-data -show-kernel

在内核模块中:

void **sys_call_table;
asmlinkage long(*original_call_ioctl)(unsigned int, unsigned int, unsigned long);

asmlinkage long our_sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg){
    return original_call_ioctl(fd, cmd, arg);
}


static int __init my_trap_init(void){
    sys_call_table = (void*)0xc000d984;

    original_call_ioctl = sys_call_table[__NR_ioctl];
    sys_call_table[__NR_ioctl] = our_sys_ioctl;

    return 0;
}

static void __exit my_trap_exit(void){
    sys_call_table[__NR_ioctl] = original_call_ioctl;
}

module_init(my_trap_init);
module_exit(my_trap_exit);

安装模块(运行无错):

insmod trapcall.ko

删除模块(内核 panic ):

rmmod trapcall.ko

删除后:

Unable to handle kernel paging request at virtual address bf000010
pgd = ed484000
[bf000010] *pgd=2d012811, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000017 [#1] PREEMPT ARM
Modules linked in: [last unloaded: trapcall]
CPU: 0    Tainted: P           O  (3.4.67-g2011b1c #6)
PC is at 0xbf000010
LR is at sys_ioctl+0x64/0x6c
pc : [<bf000010>]    lr : [<c00c4e78>]    psr: 20000013
sp : ecd55fa0  ip : 00000000  fp : 9eae0db0
r10: 00000000  r9 : ecd54000  r8 : c000d984
r7 : 00000036  r6 : acc94140  r5 : acc941a0  r4 : acc94170
r3 : 00000001  r2 : 0000000f  r1 : 00000000  r0 : 00000000
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c53c7d  Table: 2d484059  DAC: 00000015

LR: 0xc00c4df8:
4df8  eaffff6f c0045877 c0045878 c020660b 04924924 40305828 fffffdfd e92d41f3
4e18  e1a06001 e28d1004 e1a07000 e1a05002 ebffc654 e2504000 03e08008 0a00000f
4e38  e1a01006 e1a02005 eb0332a0 e2508000 1a000005 e1a00004 e1a01007 e1a02006
4e58  e1a03005 ebfffe77 e1a08000 e59d3004 e3530000 0a000001 e1a00004 ebffc701
4e78  e1a00008 e8bd81fc e92d43f8 e1a04000 e282600f e5943008 e3c66003 e3e00015
4e98  e1560003 e1a05002 e59dc020 e1cd82d8 e584000c c8bd83f8 e1a02008 e3a03000
4eb8  e1530009 01520008 e1a00008 13e0004a 1584000c 18bd83f8 e5943004 e3530000
4ed8  0a000004 e2832004 e3a03000 e482c000 e3530000 1a00002f e5947000 e3a03000

SP: 0xecd55f20:
5f20  ffffffda 00000001 00000000 00000000 ed93a190 edd8af18 ffff6201 0000000b
5f40  00000000 bf000010 20000013 ffffffff ecd55f8c c000d4f8 00000000 00000000
5f60  0000000f 00000001 acc94170 acc941a0 acc94140 00000036 c000d984 ecd54000
5f80  00000000 9eae0db0 00000000 ecd55fa0 c00c4e78 bf000010 20000013 ffffffff
5fa0  9eae0cc8 c000d800 acc94170 acc941a0 0000000f c0186201 9eae0cd0 9eae0cc8
5fc0  acc94170 acc941a0 acc94140 00000036 00000001 acd18308 af243f0d 9eae0db0
5fe0  acecd6a0 9eae0cb8 af27f9cd af267884 60000010 0000000f 9b1647f0 e3c8f8df
6000  ed751000 ee014800 00000050 ecd56050 0000000b 00000003 deca0000 ffffffff

R8: 0xc000d904:
d904  e31a0c03 1a000008 e3570d06 e24fef46 3798f107 e28d1008 e3a08000 e357080f
d924  e2270000 2a000bbd ea00a118 e1a02007 e28d1008 e3a00000 eb00068f e28fe018
d944  e1a07000 e28d1008 e3570d06 3891007f 388d0030 3798f107 eaffffee e5ad0008
d964  e1a02007 e1a0100d e3a00001 eb000682 eaffffb6 e320f000 e320f000 c04cdd74
d984  c0029558 c001ce1c c000dfac c00b59b8 c00b5a1c c00b4cf4 c00b3e78 c0035d94
d9a4  c00b4d1c c00c2f44 c00c2d8c c000dfbc c00b473c c0035d94 c00c2c8c c00b493c
d9c4  c0053828 c0035d94 c0035d94 c00b537c c0025c90 c00d09ec c0035d94 c0053898
d9e4  c0053c70 c0035d94 c0022bec c0035d94 c0035d94 c002a728 c0035d94 c0035d94

R9: 0xecd53f80:
3f80  6e1c3a3f 6e1c4a3f 6e1c5a3f 6e1c6a3f 6e1c7a3f 00000000 00000000 00000000
3fa0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fc0  00000000 00000000 00000000 6e1f6a3f 00000000 00000000 00000000 00000000
3fe0  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
4000  00000000 00000002 00000000 ed4dfc00 c04cea6c 00000000 00000015 edb34e00
4020  ed4dfc00 c04d1c78 edab9540 ec436800 00000000 ecd54000 ecd55e2c ecd55df8
4040  c036d728 00000000 00000000 00000000 00000000 00000000 01010000 01000000
4060  9eae0db0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Process Binder_1 (pid: 365, stack limit = 0xecd542e8)
Stack: (0xecd55fa0 to 0xecd56000)
5fa0: 9eae0cc8 c000d800 acc94170 acc941a0 0000000f c0186201 9eae0cd0 9eae0cc8
5fc0: acc94170 acc941a0 acc94140 00000036 00000001 acd18308 af243f0d 9eae0db0
5fe0: acecd6a0 9eae0cb8 af27f9cd af267884 60000010 0000000f 9b1647f0 e3c8f8df
[<c00c4e78>] (sys_ioctl+0x64/0x6c) from [<9eae0cc8>] (0x9eae0cc8)
Code: bad PC value
---[ end trace a19740dedb23f37c ]---
Kernel panic - not syncing: Fatal exception

我想再说一遍，其他系统调用 Hook 工作得很好。只是因“ioctl”调用而失败。

Answer 1

调用堆栈地址 sys_ioctl+0x64/0x6c 看起来像来自 sys_ioctl 的 ret 命令。

可能导致内核 panic 的工作流程:

1. 有人调用 ioctl。根据系统调用表，它解析为 our_sys_ioctl。

2. 函数 our_sys_ioctl 通过指针 original_call_ioctl 调用 sys_ioctl。像往常一样，返回地址存储在堆栈中。

3. sys_ioctl 最后调用文件系统特定的 .ioctl 函数，这可能需要很长时间才能执行(例如，等待)。

4. 另一个进程为您的模块调用 rmmod。它释放了 our_sys_ioctl 等代码。

5. 文件系统特定的 .ioctl 函数返回到 sys_ioctl。 sys_ioctl 执行其最后一个 ret 指令，该指令跳转到之前的 our_sys_ioctl 中。但是它的代码已经被释放，所以这会导致未定义的行为，这可能会导致内核崩溃。

可以使用 tail call 消除这种竞争条件, 当第2步存储在栈上的地址实际上是our_sys_ioctl的返回地址。

但是调用 our_sys_ioctl 和释放此函数的代码之间的竞争是不可避免的。最好不要卸载替换系统调用的模块。