Android goldfish內核IOCTL系統調用鈎子內核崩潰

Question

我修改了一些系統調用。 除了“ ioctl”，其他所有工具都運行良好。 當我嘗試在內核模塊上“ rmmod”時，我看到內核崩潰。 我在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

卸下模塊（內核崩潰）：

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

我想再說一遍，其他系統調用掛鈎都很好用。 只是失敗與“ ioctl”調用。

Answer 1

調用堆棧地址sys_ioctl+0x64/0x6c看起來像ret從命令sys_ioctl 。

可能導致內核崩潰的工作流程：

1. 有人稱ioctl。 根據syscall表，它解析為our_sys_ioctl 。

2. 函數our_sys_ioctl通過指針original_call_ioctl調用sys_ioctl 。 返回地址照常存儲在堆棧中。

3. sys_ioctl ， sys_ioctl調用特定於文件系統的.ioctl函數，這可能需要很長時間才能執行（例如，等待）。

4. 另一個進程為模塊調用rmmod 。 它釋放了our_sys_ioctl代碼。

5. 文件系統特定的.ioctl函數返回sys_ioctl 。 sys_ioctl執行最后一條ret指令，該指令在先前的our_sys_ioctl內部our_sys_ioctl 。 但是它的代碼已經被釋放，因此這導致未定義的行為 ，這可能導致內核崩潰。

當棧中第2步中存儲的地址實際上是our_sys_ioctl返回地址時，可以通過使用尾調用來消除這種競爭條件。

但是在調用our_sys_ioctl和釋放該函數的代碼之間的our_sys_ioctl是不可避免的 。 最好不要卸載完全替代系統調用的模塊。