title: Relocating position independent code in linux loadable kernel module
body: <p>When the LKM is loaded the code is placed in a virtual page space (vmalloc).  I'm trying to relocate a function so that it can be called regardless of processor/memory context (ie from an FIQ).  I believe this means compiling the function with PIC and then copying to a kmalloc'd space.</p>
  
  <p>I have created a function in reloc_test.c:</p>
  
  <pre><code>unsigned int test_call(unsigned int arg)
  {
      if(arg &gt; 256) {
          return 2;
      } else if(arg &lt; 256) {
          return 1;
      } else {
          return 0;
      }
  }
  </code></pre>
  
  <p>This is compiled with <code>gcc -S -fPIC -mfloat-abi=softfp -o reloc_test_asm.S reloc_test.c</code> to create as assembly file (only way I could think of to make the function PIC. </p>
  
  <pre><code>  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
  </code></pre>
  
  <p>I get the size from objdump:</p>
  
  <pre><code> $ 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
  </code></pre>
  
  <p>I then have an init for the lkm as follows:</p>
  
  <pre><code>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;
  }
  </code></pre>
  
  <p>This appears to die horribly in a kernel panic when in insmod:</p>
  
  <pre><code>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 : [&lt;db08c000&gt;]    lr : [&lt;bf0070e0&gt;]    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] [&lt;bf0070e0&gt;] (pulse_logger_init [pulse_logger_comp]) from [&lt;c00095e0&gt;] (do_one_initcall+0x90/0x1ec)
  Sep 24 20:15:04 zTorque kernel: [13329.806321] [&lt;c00095e0&gt;] (do_one_initcall) from [&lt;c008b860&gt;] (do_init_module+0x6c/0x1c8)
  Sep 24 20:15:04 zTorque kernel: [13329.820432] [&lt;c008b860&gt;] (do_init_module) from [&lt;c008d374&gt;] (load_module+0x187c/0x1f34)
  Sep 24 20:15:04 zTorque kernel: [13329.834463] [&lt;c008d374&gt;] (load_module) from [&lt;c008db08&gt;] (SyS_init_module+0xdc/0x138)
  Sep 24 20:15:04 zTorque kernel: [13329.848369] [&lt;c008db08&gt;] (SyS_init_module) from [&lt;c000f700&gt;] (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 ]---
  </code></pre>
  
  <p>Is there something protecting the kernel from executing from this space?</p>