linux-kernel-module-cheat
linux-kernel-module-cheat copied to clipboard
Allowing GDB to call functions in guest kernel
Unclear if this bug is everyone, or just me, but.
To get around E14 errors when you try to call into the guest kernel, you have to modify qemu's gdbstub.c such that if gdb_read_register returns 0, you force it to 4 or 8 (usually 8).
To actually execute code, you must disable NX with noexec=off and noexec32=off.
You don't get access to all functions, but you get more than you get from a kernel module. Some goop with -rdynamic, -E, and objcopy -w -G* should fix this.
Can you also make:
- stack overflow question
- post on QEMU mailing list. Edit: link to Dan's thread on QEMU devel: http://lists.nongnu.org/archive/html/qemu-devel/2018-02/msg03244.html
and link to them from this issue?
If something needs to be patched here, I will definitely accept it to make this awesome functionality work.
I'd rather have the QEMU part upstreamed first though if we need to patch QEMU.
Can you confirm you have the same bug?
Yes, I reproduce what you said.
Some symbols are weirdly not visible to call even though b sees them, and those that call can see fail to execute with E14 errors.
E.g.: if I break on sys_write on /count.sh:
>>> call printk(0, "asdf")
Could not fetch register "orig_rax"; remote failure reply 'E14'
>>> b printk
Breakpoint 2 at 0xffffffff81091bca: file kernel/printk/printk.c, line 1824.
>>> call fdget_pos(fd)
No symbol "fdget_pos" in current context.
>>> b fdget_pos
Breakpoint 3 at 0xffffffff811615e3: fdget_pos. (9 locations)
>>>
even though fdget_pos is the first thing sys_write does:
81 SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
582 size_t, count)
583 {
584 struct fd f = fdget_pos(fd);
I spun up a thread on qemu-devel.
You can't call printk remotely, because the kernel doesn't have a malloc. Unless you add one, like:
void *malloc(unsigned long long sz){ return kmalloc(sz, GFP_KERNEL); } void free(void *ptr) { kfree(ptr); }
I put this in printk.c and printk started working when called. Not obviously necessary.
Hmm, I also noticed that the same error message:
Could not fetch register "orig_rax"; remote failure reply 'E14'
happens when I try to end many functions with:
fin
Found the bug, it’s in the gdb stub. Basically it doesn’t know how big a register is and pukes. I have a cheap fix where I just tell it to send 8, but I’d like to fix this right.
On Sun, Apr 15, 2018 at 2:41 AM Ciro Santilli 包子露宪 六四事件 法轮功 < [email protected]> wrote:
Hmm, I also noticed that the same error message:
Could not fetch register "orig_rax"; remote failure reply 'E14'
happens when I try to end many functions with:
fin
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cirosantilli/linux-kernel-module-cheat/issues/19#issuecomment-381393288, or mute the thread https://github.com/notifications/unsubscribe-auth/ACAl5ivZkU3qYp9yfQ3ER-S0_a-vIY5Gks5toxXigaJpZM4SC8yy .