c - Kernel sys_call_table address does not match address specified in system.map -

i trying brush on c have been playing around linux kernel's system call table (on 3.13.0-32-generic). found resource online searches system call table following function load kernel in lkm:

static uint64_t **aquire_sys_call_table(void) {     uint64_t offset = page_offset;     uint64_t **sct;      while (offset < ullong_max) {         sct = (uint64_t **)offset;          if (sct[__nr_close] == (uint64_t *) sys_close) {             printk("\nsys_call_table found @ address: 0x%p\n", sys_call_table);             return sct;         }          offset += sizeof(void *);     }      return null; } 

the function works. able use address returns manipulate system call table. don't understand why address returned function doesn't match address in /boot/system.map-(kernel)

here function prints:

sys_call_table found @ address: 0xffff880001801400 

here when search system.map

$ sudo cat /boot/system.map-3.13.0-32-generic | grep sys_call_table    ffffffff81801400 r sys_call_table   ffffffff81809cc0 r ia32_sys_call_table 

why don't 2 addresses match? understanding module runs in kernel's address space, address of system call table should same.

the 2 virtual addresses have same physical address.

from documentation/x86/x86_64/mm.txt

<previous description obsolete, deleted>  virtual memory map 4 level page tables:  0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused [48:63] sign extension ffff800000000000 - ffff87ffffffffff (=43 bits) guard hole, reserved hypervisor ffff880000000000 - ffffc7ffffffffff (=64 tb) direct mapping of phys. memory ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1tb) ... unused hole ... ffffec0000000000 - fffffc0000000000 (=44 bits) kasan shadow memory (16tb) ... unused hole ... ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks ... unused hole ... ffffffff80000000 - ffffffffa0000000 (=512 mb)  kernel text mapping, phys 0 ffffffffa0000000 - ffffffffff5fffff (=1525 mb) module mapping space ffffffffff600000 - ffffffffffdfffff (=8 mb) vsyscalls ffffffffffe00000 - ffffffffffffffff (=2 mb) unused hole  direct mapping covers memory in system highest memory address (this means in cases can include pci memory holes).  vmalloc space lazily synchronized different pml4 pages of processes using page fault handler, init_level4_pgt reference.  current x86-64 implementations support 40 bits of address space, support 46 bits. expands mbz space in page tables.  ->trampoline_pgd:  map efi runtime services in aforementioned pgd in virtual range of 64gb (arbitrarily set, can raised if needed)  0xffffffef00000000 - 0xffffffff00000000  -andi kleen, jul 2004 

we know virtual address space ffff880000000000-ffffc7ffffffffff direct mapping of physical memory. when kernel wants access physical memory, uses direct mapping. it's use searching.

and ffffffff80000000-ffffffffa0000000 kernel text mapping. when kernel code executed, rip register uses kernel text mapping.

in arch/x86/include/asm/page_64.h, can relation of virtual address , physical address.

static inline unsigned long __phys_addr_nodebug(unsigned long x) {     unsigned long y = x - __start_kernel_map;      /* use carry flag determine if x < __start_kernel_map */     x = y + ((x > y) ? phys_base : (__start_kernel_map - page_offset));      return x; } 

and

// arch/x86/include/asm/page_types.h #define page_offset     ((unsigned long)__page_offset) // arch/x86/include/asm/page_64_types.h #define __start_kernel_map  _ac(0xffffffff80000000, ul) #define __page_offset           _ac(0xffff880000000000, ul) 

---

addresses mentioned in question above:

what function prints,

sys_call_table found @ address: 0xffff880001801400 

what system.map gives,

$ sudo cat /boot/system.map-3.13.0-32-generic | grep sys_call_table    ffffffff81801400 r sys_call_table   ffffffff81809cc0 r ia32_sys_call_table 

both of them resolve same physical address.

virt->phys conversion happens in such way corresponding addresses in 'direct' mapping region , 'kernel text' mapping region resolve same physical address.