Skip to content

Allowing GDB to call functions in guest kernel #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dakami opened this issue Feb 12, 2018 · 6 comments
Open

Allowing GDB to call functions in guest kernel #19

dakami opened this issue Feb 12, 2018 · 6 comments

Comments

@dakami
Copy link

dakami commented Feb 12, 2018

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.

@cirosantilli
Copy link
Owner

cirosantilli commented Feb 13, 2018

Can you also make:

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.

@dakami
Copy link
Author

dakami commented Feb 13, 2018

Can you confirm you have the same bug?

@cirosantilli
Copy link
Owner

cirosantilli commented Feb 13, 2018

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

@dakami
Copy link
Author

dakami commented Feb 13, 2018

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.

@cirosantilli
Copy link
Owner

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

@dakami
Copy link
Author

dakami commented Apr 15, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants