Add support for DWARF debug info usage for kernel module address symbolization #1391
Conversation
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 <[email protected]>
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 <[email protected]>
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
src/kernel/modmap.rs
Outdated
| } | ||
|
|
||
| // 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.
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. Signed-off-by: Daniel Müller <[email protected]>
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.79% 95.42% -0.38%
==========================================
Files 61 63 +2
Lines 11075 11359 +284
==========================================
+ Hits 10609 10839 +230
- Misses 466 520 +54 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3 participants
Please see individual commits for descriptions.