Ядро Android goldfish IOCTL, системный вызов, хук ядра, паника

Я изменил некоторые системные вызовы. Кроме "ioctl", все они работают хорошо. Когда я пытаюсь «rmmod» в моем модуле ядра, я вижу панику ядра. Я использую ядро ​​android-goldfish-3.4 в эмуляторе Android.

Запускаем эмулятор с кастомным ядром:

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».


c linux-kernel android android-kernel
person Community    schedule 13.03.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Адрес стека вызовов sys_ioctl+0x64/0x6c выглядит как команда ret из файла sys_ioctl.

Возможный рабочий процесс, который приводит к панике ядра:

  1. Кто-то вызывает ioctl. Согласно таблице системных вызовов, он разрешается в our_sys_ioctl.

  2. Функция our_sys_ioctl вызывает sys_ioctl через указатель original_call_ioctl. Адрес возврата, как обычно, хранится в стеке.

  3. sys_ioctl в конце вызывает специфичную для файловой системы функцию .ioctl, выполнение которой может потребовать много времени (например, ожидание).

  4. Другой процесс вызывает rmmod для вашего модуля. Помимо прочего, он освобождает код our_sys_ioctl.

  5. Специфичная для файловой системы функция .ioctl возвращается в sys_ioctl. sys_ioctl выполняет свою последнюю инструкцию ret, которая переходит внутрь прежней our_sys_ioctl. Но его код уже освобожден, так что это приводит к неопределенному поведению, что может вызвать панику ядра.

Такое состояние гонки можно устранить, используя вызов хвоста, когда адрес, сохраненный на шаге 2 в стеке , на самом деле является обратным адресом our_sys_ioctl.

Но гонка между вызовом our_sys_ioctl и освобождением кода этой функции неизбежна. Модуль, заменяющий системный вызов, лучше вообще не выгружать.

person Tsyvarev    schedule 13.03.2016
comment
спасибо за комментарий. Я решил эту проблему, используя потокобезопасный счетчик. я увеличиваю значение в системных вызовах. Также я уменьшаюсь после вызова. В функции exit_module я жду, когда это значение достигнет нуля. - person ; 13.03.2016