Ядро Linux: пример подключения к системному вызову

Я пытаюсь написать простой тестовый код в качестве демонстрации подключения таблицы системных вызовов.

"sys_call_table" больше не экспортируется в 2.6, поэтому я просто хватаю адрес из файла System.map, и я вижу, что это правильно (просматривая память по указанному адресу, я вижу указатели на системные вызовы).

Однако, когда я пытаюсь изменить эту таблицу, ядро дает "Oops" с "неспособным обрабатывать запрос подкачки ядра при виртуальном адресе c061e4f4", и машина перезагружается.

Это CentOS 5.4 под управлением 2.6.18-164.10.1.el5. Есть ли какая-то защита или у меня есть ошибка? Я знаю, что он поставляется с SELinux, и я попытался включить его в разрешающий режим, но это не имеет никакого значения.

Здесь мой код:

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/unistd.h>

void **sys_call_table;

asmlinkage int (*original_call) (const char*, int, int);

asmlinkage int our_sys_open(const char* file, int flags, int mode)
{
   printk("A file was opened\n");
   return original_call(file, flags, mode);
}

int init_module()
{
    // sys_call_table address in System.map
    sys_call_table = (void*)0xc061e4e0;
    original_call = sys_call_table[__NR_open];

    // Hook: Crashes here
    sys_call_table[__NR_open] = our_sys_open;
}

void cleanup_module()
{
   // Restore the original call
   sys_call_table[__NR_open] = original_call;
}

Ответ 1

Наконец-то я нашел ответ.

http://www.linuxforums.org/forum/linux-kernel/133982-cannot-modify-sys_call_table.html

Ядро было изменено в какой-то момент, так что таблица системных вызовов читается только.

шифропанк:

Даже если поздно, но решение могут заинтересовать и других: в Файл entry.S вы найдете: Код:
.section .rodata,"a"
#include "syscall_table_32.S"
sys_call_table → ReadOnly Вы должны скомпилируйте новое ядро, если вы хотите "взломать" с помощью sys_call_table...

В ссылке также есть пример изменения памяти для записи.

nasekomoe:

Привет всем. Спасибо за ответы. я давно решили проблему изменение доступа к страницам памяти. я реализовали две функции, которые это для моего кода верхнего уровня:
#include <asm/cacheflush.h>
#ifdef KERN_2_6_24
#include <asm/semaphore.h>
int set_page_rw(long unsigned int _addr)
{
    struct page *pg;
    pgprot_t prot;
    pg = virt_to_page(_addr);
    prot.pgprot = VM_READ | VM_WRITE;
    return change_page_attr(pg, 1, prot);
}

int set_page_ro(long unsigned int _addr)
{
    struct page *pg;
    pgprot_t prot;
    pg = virt_to_page(_addr);
    prot.pgprot = VM_READ;
    return change_page_attr(pg, 1, prot);
}

#else
#include <linux/semaphore.h>
int set_page_rw(long unsigned int _addr)
{
    return set_memory_rw(_addr, 1);
}

int set_page_ro(long unsigned int _addr)
{
    return set_memory_ro(_addr, 1);
}

#endif // KERN_2_6_24

Здесь изменена версия исходного кода, которая работает для меня.

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/unistd.h>
#include <asm/semaphore.h>
#include <asm/cacheflush.h>

void **sys_call_table;

asmlinkage int (*original_call) (const char*, int, int);

asmlinkage int our_sys_open(const char* file, int flags, int mode)
{
   printk("A file was opened\n");
   return original_call(file, flags, mode);
}

int set_page_rw(long unsigned int _addr)
{
   struct page *pg;
   pgprot_t prot;
   pg = virt_to_page(_addr);
   prot.pgprot = VM_READ | VM_WRITE;
   return change_page_attr(pg, 1, prot);
}

int init_module()
{
    // sys_call_table address in System.map
    sys_call_table = (void*)0xc061e4e0;
    original_call = sys_call_table[__NR_open];

    set_page_rw(sys_call_table);
    sys_call_table[__NR_open] = our_sys_open;
}

void cleanup_module()
{
   // Restore the original call
   sys_call_table[__NR_open] = original_call;
}

Ответ 2

Спасибо Стивену, ваши исследования здесь были полезны для меня. У меня было несколько проблем, хотя я пытался это сделать на ядре 2.6.32 и получаю WARNING: at arch/x86/mm/pageattr.c:877 change_page_attr_set_clr+0x343/0x530() (Not tainted), за которым следует OOPS ядра, о невозможности записи на адрес памяти.

Комментарий выше указанной строки гласит:

// People should not be passing in unaligned addresses

Работает следующий модифицированный код:

int set_page_rw(long unsigned int _addr)
{
    return set_memory_rw(PAGE_ALIGN(_addr) - PAGE_SIZE, 1);
}

int set_page_ro(long unsigned int _addr)
{
    return set_memory_ro(PAGE_ALIGN(_addr) - PAGE_SIZE, 1);
}

Обратите внимание, что это по-прежнему не устанавливает страницу как чтение/запись в некоторых ситуациях. Функция static_protections(), которая вызывается внутри set_memory_rw(), удаляет флаг _PAGE_RW, если:

В области BIOS
Адрес находится внутри .rodatali >
Установлен CONFIG_DEBUG_RODATA, а ядро настроено на чтение только

Я нашел это после отладки, почему я все еще "не мог обработать запрос подкачки ядра" при попытке изменить адрес функций ядра. В конечном итоге я смог решить эту проблему, самостоятельно найдя запись в таблице для адреса и вручную настроив ее на запись. К счастью, функция lookup_address() экспортируется в версии 2.6.26+. Вот код, который я написал для этого:

void set_addr_rw(unsigned long addr) {

    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);

    if (pte->pte &~ _PAGE_RW) pte->pte |= _PAGE_RW;

}

void set_addr_ro(unsigned long addr) {

    unsigned int level;
    pte_t *pte = lookup_address(addr, &level);

    pte->pte = pte->pte &~_PAGE_RW;

}

Наконец, в то время как ответ Марка технически корректен, проблема будет возникать при запуске внутри Xen. Если вы хотите отключить защиту от записи, используйте функции чтения/записи cr0. Я делаю макрос таким образом:

#define GPF_DISABLE write_cr0(read_cr0() & (~ 0x10000))
#define GPF_ENABLE write_cr0(read_cr0() | 0x10000)

Надеюсь, это поможет кому-то еще, кто наткнулся на этот вопрос.

Ответ 3

Обратите внимание, что вместо использования change_page_attr также будет работать следующее:

static void disable_page_protection(void) {

    unsigned long value;
    asm volatile("mov %%cr0,%0" : "=r" (value));
    if (value & 0x00010000) {
            value &= ~0x00010000;
            asm volatile("mov %0,%%cr0": : "r" (value));
    }
}

static void enable_page_protection(void) {

    unsigned long value;
    asm volatile("mov %%cr0,%0" : "=r" (value));
    if (!(value & 0x00010000)) {
            value |= 0x00010000;
            asm volatile("mov %0,%%cr0": : "r" (value));
    }
}

Ответ 4

Если вы имеете дело с ядром 3.4 и более поздними версиями (он также может работать с более ранними ядрами, я не тестировал его), я бы рекомендовал более разумный способ получить расположение таблицы системных вызовов.

Например

#include <linux/module.h>
#include <linux/kallsyms.h>

static unsigned long **p_sys_call_table;
/* Aquire system calls table address */
p_sys_call_table = (void *) kallsyms_lookup_name("sys_call_table");

Что это. Нет адресов, он отлично работает с каждым тестируемым ядром.

Точно так же вы можете использовать не экспортированную функцию Kernel из вашего модуля:

static int (*ref_access_remote_vm)(struct mm_struct *mm, unsigned long addr,
                void *buf, int len, int write);
ref_access_remote_vm = (void *)kallsyms_lookup_name("access_remote_vm");

Наслаждайтесь!

Ответ 5

Используя следующее

address = (void *) kallsyms_lookup_name("linux_banner");
printk(KERN_INFO "Address of linux_banner is [0x%lx]\n", (unsigned long) address);

address = (void *) kallsyms_lookup_name("sys_call_table");
printk(KERN_INFO "Address of sys_call_table is [0x%lx]\n", (unsigned long) address);

address = (void *) kallsyms_lookup_name("vdso_image_64");
printk(KERN_INFO "Address of vdso_image_64 is [0x%lx]\n", (unsigned long) address);

печать

Address of linux_banner is [0xffffffff95c00120]
Address of sys_call_table is [0xffffffff95c00220]
Address of vdso_image_64 is [0xffffffff95c013c0]

тогда как их соответствующие адреса (согласно файлу System.map)

ffffffff81e00120 R linux_banner
ffffffff81e00220 R sys_call_table
ffffffff81e013c0 R vdso_image_64

Есть идеи, почему это постоянное смещение в адресах?