web-dev-qa-db-ja.com

Linux Kernel:システムコールフックの例

システムコールテーブルをフックするデモとして、簡単なテストコードを記述しようとしています。

「sys_call_table」は2.6ではエクスポートされなくなったため、System.mapファイルからアドレスを取得するだけで、正しいことがわかります(見つけたアドレスのメモリを見ると、システムコール)。

ただし、この表を変更しようとすると、カーネルは「仮想アドレスc061e4f4でカーネルページング要求を処理できません」という「エラー」を表示し、マシンが再起動します。

これは2.6.18-164.10.1.el5を実行するCentOS 5.4です。何らかの保護がありますか、それともバグがありますか?私はそれが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;
}
65
Stephen

私は最終的に自分で答えを見つけました。

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:

みなさん、こんにちは。返信いただきありがとうございます。メモリページへのアクセスを変更することで、ずっと前に問題を解決しました。上位レベルのコードに対してそれを行う2つの関数を実装しました。

#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;
}
54
Stephen

スティーブンに感謝します、あなたの研究は私にとって役に立ちました。しかし、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領域にあります
  • アドレスは.rodata内にあります
  • 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;

}
_

最後に、Markの答えは技術的には正しいものの、Xen内で実行すると問題が発生します。書き込み保護を無効にする場合は、読み取り/書き込みcr0関数を使用します。私は次のようにそれらをマクロ化します:

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

これが、この質問につまずく他の誰にも役立つことを願っています。

24
Corey Henderson

以下は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));
    }
}
18
mark

カーネル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");

それでおしまい。アドレスはありません。テストしたすべてのカーネルで正常に動作します。

モジュールからエクスポートされていないカーネル関数を使用できるのと同じ方法:

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");

楽しい!

10