Add support for DWARF debug info usage for kernel module address symbolization#1391
Add support for DWARF debug info usage for kernel module address symbolization#1391d-e-s-o merged 5 commits intolibbpf:mainfrom
Conversation
danielocfb
force-pushed
the
topic/kernel-mod-syms
branch
4 times, most recently
from
5941d58 to
a2e3f78
Compare
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
4 times, most recently
from
ace6526 to
c724915
Compare
danielocfb
added
the
blocked
anakryiko
left a comment
anakryiko
left a comment
There was a problem hiding this comment.
looks good, great to see this happening (and sorry for delay!)
left minor questions/comments, but non are blocking
| } | ||
|
|
||
| // Each line has format: | ||
| // <module_name> <size> <instances> <dependencies> <state> <offset> |
There was a problem hiding this comment.
nit: not offset, absolute start address (and just for comment completeness there could be extra flags afterwards in ()
| let addr = if let Ok(addr) = Addr::from_str_radix(addr.trim_start_matches("0x"), 16) { | ||
| // A start address of 0 means that the address was | ||
| // masked -- it is not usable for our purposes. | ||
| if addr == 0 { |
There was a problem hiding this comment.
do you have some means to emit warning (for debugging)? might be useful
looking at kernel code (I was curious how this /proc/modules file is generated), I think either all module addresses will be zero (if kptr_restrict sysctl is set, or not enough capabilities to see real kernel address) or they will all be valid, so you can really break out of here and save time (and logging spam, if you decide to log this condition)
There was a problem hiding this comment.
I think the way it would manifest is that we'd report Reason::MissingSyms when symbolizing and there are no modules. It's the same mechanism we use for stripped ELF binaries or masked /proc/kallsyms addresses.
|
|
||
|
|
||
| #[cfg(feature = "xz")] | ||
| fn decompress_xz(path: &Path) -> Result<NamedTempFile> { |
There was a problem hiding this comment.
curious, will this temporary file be deleted by blazesym when ElfResolver is destroyed, or it will stay in /tmp and is expected to be cleaned up eventually outside of blazesym's control?
There was a problem hiding this comment.
Yep, once the NamedTempFile leaves scope the file will be removed (so in this case that would be by the time KernelResolver::find_sym returns, on the current call path), so there shouldn't be any left overs.
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
from
c724915 to
a332212
Compare
|
Rebased and address review comments. Thanks for the review. This support is still blocked on ELF relocations and/or additional testing. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1391 +/- ##
==========================================
+ Coverage 95.53% 95.60% +0.06%
==========================================
Files 54 56 +2
Lines 9213 9500 +287
==========================================
+ Hits 8802 9082 +280
- Misses 411 418 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
2 times, most recently
from
f972e4a to
b11be98
Compare
Adjust our CI infra to build the test_hexdump kernel module with DWARF debug information. We shall use this module for testing of kernel module symbolization support down the line. To that end, already make sure that we load it when running the main test suite. We are also going to need to enable module unload support for our kernel, because otherwise /proc/modules are b0rked. Signed-off-by: Daniel Müller <deso@posteo.net>
Add an integration test for kernel module symbolization using DWARF debug information. Signed-off-by: Daniel Müller <deso@posteo.net>
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
2 times, most recently
from
c5ac5fd to
4043f56
Compare
d-e-s-o
removed
the
blocked
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
5 times, most recently
from
f93fde0 to
ea692e7
Compare
Add a parser for /proc/modules style files, ModMap. /proc/modules contains information about memory ranges of modules. We need such information in order to understand which module a given kernel address belongs to. On top of just parsing contents, objects of this type provide the means for querying the module name that an address belongs to, if any. Signed-off-by: Daniel Müller <deso@posteo.net>
Add logic for parsing depmod binary files. These files basically contain a search tree for efficiently looking up module paths (relative to a base directory) given a module name. Making such a lookup possible enables the loading of module binaries, which may contain DWARF debug information for symbolization that resolves source code information (as opposed to /proc/kallsyms, which only has limited function granularity for addresses). Signed-off-by: Daniel Müller <deso@posteo.net>
Add support for looking up and incorporating DWARF information for symbolization of kernel module addresses. So far we have only supported using DWARF for addresses belonging to the core kernel. We rely on the previously introduced /proc/modules map for deciding whether an address belongs to a kernel module. We then use the depmod file for looking up the kernel module, optionally taking into account debug links as usual. We also support compressed kernel modules and decompress them transparently on the fly. To make that work, add the flat2 dependency to handle gzip headers properly. That requires us to downgrade miniz_oxide, because upstream can't get their act together and update, and we certainly don't want to duplicate the dependency. Signed-off-by: Daniel Müller <deso@posteo.net>
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
from
ea692e7 to
e70d36a
Compare
d-e-s-o
force-pushed
the
topic/kernel-mod-syms
branch
from
e70d36a to
95a9afe
Compare
3 participants
Please see individual commits for descriptions.