堆棧內存溢出
  簡體   English   中英

在linux可加載內核模塊中重定位與位置無關的代碼

[英]Relocating position independent code in linux loadable kernel module

 原文  2015-09-24 20:18:39  3   1    c/ linux/ assembly

問題描述

加載LKM時，代碼將放置在虛擬頁面空間（vmalloc）中。 我正在嘗試重定位函數，以便無論處理器/內存上下文如何（即從FIQ）都可以調用它。 我相信這意味着使用PIC編譯功能，然后復制到kmalloc的空間中。

我在reloc_test.c中創建了一個函數： 

unsigned int test_call(unsigned int arg)
{
    if(arg > 256) {
        return 2;
    } else if(arg < 256) {
        return 1;
    } else {
        return 0;
    }
}

使用gcc -S -fPIC -mfloat-abi=softfp -o reloc_test_asm.S reloc_test.c進行編譯，以將其創建為程序集文件（只有這樣我才能想到制作函數PIC。 

  1   .arch armv6
  2   .eabi_attribute 27, 3
  3   .eabi_attribute 28, 1
  4   .fpu vfp
  5   .eabi_attribute 20, 1
  6   .eabi_attribute 21, 1
  7   .eabi_attribute 23, 3
  8   .eabi_attribute 24, 1
  9   .eabi_attribute 25, 1
 10   .eabi_attribute 26, 2
 11   .eabi_attribute 30, 6
 12   .eabi_attribute 34, 1
 13   .eabi_attribute 18, 4
 14   .file "reloc_test.c"
 15   .text
 16   .align  2
 17   .global test_call
 18   .type test_call, %function
 19 test_call:
 20   @ args = 0, pretend = 0, frame = 8
 21   @ frame_needed = 1, uses_anonymous_args = 0
 22   @ link register save eliminated.
 23   str fp, [sp, #-4]!
 24   add fp, sp, #0
 25   sub sp, sp, #12
 26   str r0, [fp, #-8]
 27   ldr r3, [fp, #-8]
 28   cmp r3, #256
 29   bls .L2
 30   mov r3, #2
 31   b .L3
 32 .L2:
 33   ldr r3, [fp, #-8]
 34   cmp r3, #255
 35   bhi .L4
 36   mov r3, #1
 37   b .L3
 38 .L4:
 39   mov r3, #0
 40 .L3:
 41   mov r0, r3
 42   sub sp, fp, #0
 43   @ sp needed
 44   ldr fp, [sp], #4
 45   bx  lr
 46   .size test_call, .-test_call
 47   .ident  "GCC: (Raspbian 4.8.4-1) 4.8.4"
 48   .section  .note.GNU-stack,"",%progbits

我從objdump獲得大小： 

 $ objdump -t reloc_test_asm.o

reloc_test_asm.o:     file format elf32-littlearm

SYMBOL TABLE:
00000000 l    df *ABS*  00000000 reloc_test.c
00000000 l    d  .text  00000000 .text
00000000 l    d  .data  00000000 .data
00000000 l    d  .bss   00000000 .bss
00000000 l    d  .note.GNU-stack        00000000 .note.GNU-stack
00000000 l    d  .comment       00000000 .comment
00000000 l    d  .ARM.attributes        00000000 .ARM.attributes
00000000 g     F .text  0000004c test_call

然后，我有一個lkm的初始化，如下所示： 

unsigned int test_call(unsigned int arg);
static int __init pulse_logger_init(void)
{
    unsigned int (*test)(unsigned int arg);
    static void* buffer;
    printk(KERN_INFO "%s\n", __func__);

    printk(KERN_INFO "test_call retuns: %d %d %d\n", test_call(0), test_call(256), test_call(512));

    buffer = (void *)__get_free_pages(GFP_KERNEL, THREAD_SIZE_ORDER);
    buffer = (void*) ALIGN((uint32_t)buffer, 4);
    printk(KERN_INFO "\t  buffer(%#10X)\n", (unsigned int)buffer);
    printk(KERN_INFO "\t  test_call(%#10X)\n", (unsigned int)test_call);
    memcpy(buffer, test_call, 0x4c);
    test = (unsigned int (*)(unsigned int)) buffer;
    printk(KERN_INFO "test_call retuns: %d %d %d\n", test_call(0), test(256), test(512));
    __free_pages(buffer, THREAD_SIZE_ORDER);

    return 0;
}

在insmod中，這似乎在內核恐慌中可怕地死亡： 

Sep 24 20:15:04 zTorque kernel: [13329.307348] pulse_logger_init
Sep 24 20:15:04 zTorque kernel: [13329.307389] test_call retuns: 1 0 2
Sep 24 20:15:04 zTorque kernel: [13329.307437]    buffer(0XDB08C000)
Sep 24 20:15:04 zTorque kernel: [13329.307451]    test_call(0XBF004570)
Sep 24 20:15:04 zTorque kernel: [13329.307482] Unable to handle kernel paging request at virtual address db08c000
Sep 24 20:15:04 zTorque kernel: [13329.320232] pgd = db0d4000
Sep 24 20:15:04 zTorque kernel: [13329.328257] [db08c000] *pgd=1b00041e(bad)
Sep 24 20:15:04 zTorque kernel: [13329.337622] Internal error: Oops: 8000000d [#1] PREEMPT ARM
Sep 24 20:15:04 zTorque kernel: [13329.348528] Modules linked in: pulse_logger_comp(O+) cfg80211 rfkill snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer                                                                                  snd uio_pdrv_genirq uio
Sep 24 20:15:04 zTorque kernel: [13329.367327] CPU: 0 PID: 2452 Comm: insmod Tainted: G           O    4.1.5+ #809
Sep 24 20:15:04 zTorque kernel: [13329.380234] Hardware name: BCM2708
Sep 24 20:15:04 zTorque kernel: [13329.389186] task: dd352940 ti: dc83a000 task.ti: dc83a000
Sep 24 20:15:04 zTorque kernel: [13329.400168] PC is at 0xdb08c000
Sep 24 20:15:04 zTorque kernel: [13329.408893] LR is at pulse_logger_init+0xe0/0x130 [pulse_logger_comp]
Sep 24 20:15:04 zTorque kernel: [13329.420960] pc : [<db08c000>]    lr : [<bf0070e0>]    psr: 80000013
Sep 24 20:15:04 zTorque kernel: [13329.420960] sp : dc83bdb0  ip : 00000007  fp : dc83bdd4
Sep 24 20:15:04 zTorque kernel: [13329.443668] r10: c008a32c  r9 : 00000000  r8 : 00000001
Sep 24 20:15:04 zTorque kernel: [13329.454552] r7 : bf004658  r6 : bf004b00  r5 : bf004570  r4 : db08c000
Sep 24 20:15:04 zTorque kernel: [13329.466776] r3 : 00000001  r2 : e3530c01  r1 : e51b3008  r0 : 00000100
Sep 24 20:15:04 zTorque kernel: [13329.478944] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Sep 24 20:15:04 zTorque kernel: [13329.491711] Control: 00c5387d  Table: 1b0d4008  DAC: 00000015
Sep 24 20:15:04 zTorque kernel: [13329.503052] Process insmod (pid: 2452, stack limit = 0xdc83a188)
Sep 24 20:15:04 zTorque kernel: [13329.514633] Stack: (0xdc83bdb0 to 0xdc83c000)
Sep 24 20:15:04 zTorque kernel: [13329.524527] bda0:                                     00000000 c081f770 c081f770 dc9544c0
Sep 24 20:15:04 zTorque kernel: [13329.538348] bdc0: dc954380 bf007000 dc83be54 dc83bdd8 c00095e0 bf00700c 00000000 00000000
Sep 24 20:15:04 zTorque kernel: [13329.552226] bde0: dcadea80 ddb5e9e0 00000000 00000000 ddb5e9e0 ddb5e9e0 dd780b34 dd780b3c
Sep 24 20:15:04 zTorque kernel: [13329.566155] be00: dc83be3c dc83be10 c00ee6c4 c00c5454 dc83be34 dc83be20 00000002 c008b824
Sep 24 20:15:04 zTorque kernel: [13329.580152] be20: df95c000 c0120a24 00000003 bf004980 00000001 db07fea0 dc954380 00000001
Sep 24 20:15:04 zTorque kernel: [13329.594180] be40: dc9543a4 c008a32c dc83be7c dc83be58 c008b860 c000955c bf0049c8 dc954380
Sep 24 20:15:04 zTorque kernel: [13329.608239] be60: dc83be7c dc83bf40 00000001 bf0049c8 dc83bf3c dc83be80 c008d374 c008b800
Sep 24 20:15:04 zTorque kernel: [13329.622269] be80: bf00498c 00007fff c008a2d0 c0313d20 00000013 00000001 df95c000 bf00498c
Sep 24 20:15:04 zTorque kernel: [13329.636272] bea0: 00000000 df95e544 bf004fe8 bf00498c b6f22948 bf004b28 bf004af0 bf004980
Sep 24 20:15:04 zTorque kernel: [13329.650319] bec0: b6f3a000 dc83a000 00002db8 00002594 00000000 bf004604 00000001 00000000
Sep 24 20:15:04 zTorque kernel: [13329.664357] bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sep 24 20:15:04 zTorque kernel: [13329.678366] bf00: 00000000 00000000 00000000 00000000 df95c000 00002594 00000000 b6f3c594
Sep 24 20:15:04 zTorque kernel: [13329.692345] bf20: df95e594 dc83a000 b6f22948 00000000 dc83bfa4 dc83bf40 c008db08 c008bb04
Sep 24 20:15:04 zTorque kernel: [13329.706345] bf40: df95c000 00002594 df95df7c df95cf87 df95d904 00000b28 00000ff8 00000000
Sep 24 20:15:04 zTorque kernel: [13329.720309] bf60: 00000000 00000000 00000025 00000026 0000001b 0000001f 00000016 00000000
Sep 24 20:15:04 zTorque kernel: [13329.734221] bf80: 00000000 00000000 80b420a8 00000080 c000f908 dc83a000 00000000 dc83bfa8
Sep 24 20:15:04 zTorque kernel: [13329.748141] bfa0: c000f700 c008da38 00000000 00000000 b6f3a000 00002594 b6f22948 b6f3a000
Sep 24 20:15:04 zTorque kernel: [13329.762118] bfc0: 00000000 00000000 80b420a8 00000080 80b41fe0 00002594 b6f22948 00000000
Sep 24 20:15:04 zTorque kernel: [13329.776113] bfe0: b6e757d0 be9426a8 b6f19fb4 b6e757e0 60000010 b6f3a000 1dbf4821 1dbf4c21
Sep 24 20:15:04 zTorque kernel: [13329.790218] [<bf0070e0>] (pulse_logger_init [pulse_logger_comp]) from [<c00095e0>] (do_one_initcall+0x90/0x1ec)
Sep 24 20:15:04 zTorque kernel: [13329.806321] [<c00095e0>] (do_one_initcall) from [<c008b860>] (do_init_module+0x6c/0x1c8)
Sep 24 20:15:04 zTorque kernel: [13329.820432] [<c008b860>] (do_init_module) from [<c008d374>] (load_module+0x187c/0x1f34)
Sep 24 20:15:04 zTorque kernel: [13329.834463] [<c008d374>] (load_module) from [<c008db08>] (SyS_init_module+0xdc/0x138)
Sep 24 20:15:04 zTorque kernel: [13329.848369] [<c008db08>] (SyS_init_module) from [<c000f700>] (ret_fast_syscall+0x0/0x54)
Sep 24 20:15:04 zTorque kernel: [13329.862562] Code: 1dbee811 1dbeec11 1dbf4821 1dbf4c21 (e52db004)
Sep 24 20:15:04 zTorque kernel: [13329.931225] ---[ end trace 213b9514d512fd18 ]---

有什么保護內核從該空間執行的方法嗎？

1 個解決方案

解決方案1
 0  2015-09-25 15:13:54

我不確定這是否是完整的答案，但內容不適合發表評論。

Ross能夠為我指明正確的方向，並且我找到了一種具有執行權限的內存分配方式： 如何在Linux內核模塊中分配可執行頁面？

這將創建以下代碼： 

printk(KERN_INFO "test_call returns: %d %d %d\n", test_call(0), test_call(256), test_call(512));

buffer = __vmalloc(0x60, GFP_KERNEL, PAGE_KERNEL_EXEC);
if(buffer != NULL){
    buffer = (void*) ALIGN((uint32_t)buffer, 4) + 4;
    printk(KERN_INFO "\t  buffer(%#10X)\n", (unsigned int)buffer);
    printk(KERN_INFO "\t  test_call(%#10X)\n", (unsigned int)test_call);
    memcpy(buffer, test_call, 0x4c);
    printk(KERN_INFO "\t  test_call copied to buffer\n");
    test = (unsigned int (*)(unsigned int)) buffer;
    printk(KERN_INFO "\t  test pointer assigned (%#10X)\n", test);
    printk(KERN_INFO "test returns: %d %d %d\n", test(0), test(256), test(512));
    vfree(buffer);
}

這將創建以下輸出： 

Sep 25 14:17:26  kernel: [  109.102562] pulse_logger_init
Sep 25 14:17:26  kernel: [  109.102626] test_call returns: 1 0 2
Sep 25 14:17:26  kernel: [  109.102701]    buffer(0XDF9D4004)
Sep 25 14:17:26  kernel: [  109.102739]    test_call(0XBF004384)
Sep 25 14:17:26  kernel: [  109.102753]    test_call copied to buffer
Sep 25 14:17:26  kernel: [  109.102766]    test pointer assigned (0XDF9D4004)
Sep 25 14:17:26  kernel: [  109.102779] test returns: 1 0 2
Sep 25 14:17:26  kernel: [  109.102793] ------------[ cut here ]------------
Sep 25 14:17:26  kernel: [  109.102836] WARNING: CPU: 0 PID: 2803 at mm/vmalloc.c:1459 __vunmap+0xe4/0xfc()
Sep 25 14:17:26  kernel: [  109.102871] Trying to vfree() bad address (df9d4004)
Sep 25 14:17:26  kernel: [  109.102884] Modules linked in: pulse_logger_comp(O+) cfg80211 rfkill snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer snd uio_pdrv_genirq uio
Sep 25 14:17:26  kernel: [  109.102979] CPU: 0 PID: 2803 Comm: insmod Tainted: G           O    4.1.5+ #809
Sep 25 14:17:26  kernel: [  109.102994] Hardware name: BCM2708
Sep 25 14:17:26  kernel: [  109.103063] [<c0016d88>] (unwind_backtrace) from [<c0013b50>] (show_stack+0x20/0x24)
Sep 25 14:17:26  kernel: [  109.103123] [<c0013b50>] (show_stack) from [<c058690c>] (dump_stack+0x20/0x28)
Sep 25 14:17:26  kernel: [  109.103170] [<c058690c>] (dump_stack) from [<c0024178>] (warn_slowpath_common+0x8c/0xc4)
Sep 25 14:17:26  kernel: [  109.103204] [<c0024178>] (warn_slowpath_common) from [<c00241f0>] (warn_slowpath_fmt+0x40/0x48)
Sep 25 14:17:26  kernel: [  109.103261] [<c00241f0>] (warn_slowpath_fmt) from [<c0120a64>] (__vunmap+0xe4/0xfc)
Sep 25 14:17:26  kernel: [  109.103294] [<c0120a64>] (__vunmap) from [<c0120b1c>] (vfree+0x50/0x90)
Sep 25 14:17:26  kernel: [  109.103339] [<c0120b1c>] (vfree) from [<bf0060fc>] (pulse_logger_init+0xfc/0x12c [pulse_logger_comp])
Sep 25 14:17:26  kernel: [  109.103415] [<bf0060fc>] (pulse_logger_init [pulse_logger_comp]) from [<c00095e0>] (do_one_initcall+0x90/0x1ec)
Sep 25 14:17:26  kernel: [  109.103465] [<c00095e0>] (do_one_initcall) from [<c008b860>] (do_init_module+0x6c/0x1c8)
Sep 25 14:17:26  kernel: [  109.103524] [<c008b860>] (do_init_module) from [<c008d374>] (load_module+0x187c/0x1f34)
Sep 25 14:17:26  kernel: [  109.103559] [<c008d374>] (load_module) from [<c008db08>] (SyS_init_module+0xdc/0x138)
Sep 25 14:17:26  kernel: [  109.103614] [<c008db08>] (SyS_init_module) from [<c000f700>] (ret_fast_syscall+0x0/0x54)
Sep 25 14:17:26  kernel: [  109.103636] ---[ end trace c37a24bf1309572d ]---

好消息是，這看起來像是為內核模式虛擬地址空間分配的（而不是頁面映射的）。 我基於這一信念，即用戶/內核拆分發生在0xC0000000。 那是否表明LKM的內核vmalloc駐留在用戶模式頁面映射的虛擬地址范圍內？

不知道為什么vfree呼叫要求一個錯誤的地址。

暫無
暫無

聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

相關問題 在可加載的Linux內核模塊上設置cpu affinity 是否可以在Linux上使用C ++開發可加載的內核模塊（LKM）？ 無法刪除可加載的內核模塊 在linux內核中攔截ELF加載程序：通過可加載內核模塊的fs / binfmt_elf.c文件 使用c語言將字符串轉換為linux可加載內核模塊中的float 使內核模塊在運行時可加載 編譯可加載的內核模塊（Debian / Ubuntu） 可加載內核模塊編程和系統調用攔截 Linux內核模塊：在運行時動態加載代碼 Linux中相互依賴的樹外內核可加載模塊
相關標簽
 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM