Add logic for reading KASLR offset #951
Conversation
In order to (eventually...) support normalization of kernel addresses, we need to take into account whether the running kernel has address space layout randomization enabled. If that is the case, we will need to incorporate the randomization offset in the normalization process. This change introduces the necessary logic for reading said offset, so that it can be used down the line. This change builds on all the infrastructure we added for making the ELF parser optionally work with using regular I/O APIs instead of relying on memory mapping. Refs: libbpf#950 Signed-off-by: Daniel Müller <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #951 +/- ##
==========================================
- Coverage 94.50% 94.28% -0.22%
==========================================
Files 57 58 +1
Lines 10603 10708 +105
==========================================
+ Hits 10020 10096 +76
- Misses 583 612 +29 ☔ View full report in Codecov by Sentry. |
d-e-s-o
force-pushed
the
topic/kaslr
branch
3 times, most recently
from
866e604 to
cf78df4
Compare
danielocfb
force-pushed
the
topic/kaslr
branch
2 times, most recently
from
12d9352 to
a87768d
Compare
src/normalize/kernel.rs
Outdated
|
|
||
| /// Try to determine the KASLR state of the system. | ||
| fn determine_kaslr_state() -> Result<KaslrState> { | ||
| // https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#randomize-va-space |
There was a problem hiding this comment.
are you sure this has anything to do with KASLR? My interpretation is that this is purely user address space randomization, which you shouldn't care about here. I think I have it on my devserver set to 1, but I don't have KASLR enabled for the kernel.
There was a problem hiding this comment.
Hm, you may be right. Let me remove this bit.
|
|
||
| // Iterate through all available notes. See `elf(5)` for | ||
| // details. | ||
| while offset + (size_of::<ElfN_Nhdr>() as u64) <= phdr.file_size() { |
There was a problem hiding this comment.
nit: blazesym parses Elf notes at least in two places now, right? Why not add a proper iterator support and clean up this code (and the one that does build ID, right?)
There was a problem hiding this comment.
Yes, I thought about it, but couldn't find a good abstraction and the implementations have to exhibit certain differences for technical reasons. It's just a few lines of code, so I think it's fine.
There was a problem hiding this comment.
No big deal and can be done as a follow up. But I do find all those offset checks, file size, etc quite mundane and error prone, so I still feel like iterator would be an improvement. It can return Nhdr + name/descr slices, which would save a bunch of error check and otherwise distracting plumbing. But up to you.
d-e-s-o
force-pushed
the
topic/kaslr
branch
2 times, most recently
from
c337f08 to
213b70d
Compare
|
|
||
| // Iterate through all available notes. See `elf(5)` for | ||
| // details. | ||
| while offset + (size_of::<ElfN_Nhdr>() as u64) <= phdr.file_size() { |
There was a problem hiding this comment.
No big deal and can be done as a follow up. But I do find all those offset checks, file size, etc quite mundane and error prone, so I still feel like iterator would be an improvement. It can return Nhdr + name/descr slices, which would save a bunch of error check and otherwise distracting plumbing. But up to you.
In order to (eventually...) support normalization of kernel addresses, we need to take into account whether the running kernel has address space layout randomization enabled. If that is the case, we will need to incorporate the randomization offset in the normalization process. This change introduces the necessary logic for reading said offset, so that it can be used down the line.
This change builds on all the infrastructure we added for making the ELF parser optionally work with using regular I/O APIs instead of relying on memory mapping.
Refs: #950