3

I've been following this guide to set up a Linux kernel debugging environment with gdb and VMWare. Everything went on smoothly until that part:

Connect GDB to the debuggee
We won’t be able to see symbols from loaded kernel modules yet. We’ll load the helper script and then run lx-symbols, which will probe the loaded modules and configure GDB appropriately:
(gdb) source home/alambert/kernel/source/linux-4.13.0/debian/build/build-generic/vmlinux-gdb.py
(gdb) lx-symbols

When running this on my system I get the following python error:
pwndbg> source /home/user/kernel/source/linux-4.4.0/debian/build/build-generic/vmlinux-gdb.py pwndbg> lx-symbols loading vmlinux Python Exception <class 'gdb.error'> There is no member named module_core.: Error occurred in Python command: There is no member named module_core.

My setup

Both the debugger and debugee machines are VMs, the debugee is a Ubuntu 16.04 and the debugger is a Ubuntu 18.04.

Debugee:
$ cat /proc/version Linux version 4.4.0-134-generic (buildd@lgw01-amd64-033) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) ) #160-Ubuntu SMP Wed Aug 15 14:58:00 UTC 2018

Debugger:
$ cat /proc/version Linux version 4.15.0-34-generic (buildd@lgw01-amd64-047) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 $ gdb --version GNU gdb (GDB) 8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ python -V Python 2.7.15rc1

I first thought it was a python3/2 compatibility issue so I recompiled gdb with python 2.7, but got the exact same error.

I have also verified it is not a pwndbg problem - I tried this with vanilla gdb to the exact same effect.

I have verified that the python helper scripts had been created in the process of compiling the debugee kernel. I actually let the whole build process complete rather than stopping it once the scripts were created like the guide suggests - just to make sure all of them are in place.

I have tried looking for the error online but there does not seem to be any mention of it.

Did anybody ever encounter that problem?

0xc3faadd3
  • 91
  • 1
  • 8
  • Could you please type `(gdb) set python print-stack full` , then enter that `source` command again, and edit your question to include the full backtrace that is displayed? – Mark Plotnick Sep 16 '18 at 00:12
  • Thank you very much Mark, I have managed to solve the issue. As I discovered, this was not a python bug but rather an inconsistency between the `module.h` header and the helper script. Thanks again for the quick response! – 0xc3faadd3 Sep 16 '18 at 00:45

1 Answers1

6

After some digging in the sources of the scripts and the linux kernel, I have managed to fix the issue.

The problem lies in this commit which replaced the module_core pointer with a module_layout struct in the include/linux/module.h header. The change had been apparently pulled into kernel 4.4.0 but was not accounted for in the helper scripts until a later version.

This had been dealt with a while later (specifically - in this commit), so all kernel versions between 4.4.0 and 4.6-rc1 will have this bug.

The solution is to download the scripts from the aforementioned commit and place them in the relevant directories.

This is certainly a rare edge-case but I hope this answer will be helpful to somebody someday.

0xc3faadd3
  • 91
  • 1
  • 8