-
Notifications
You must be signed in to change notification settings - Fork 45
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
Version check makes potentially invalid assumptions about ELF layout #174
Comments
Hi @jhance and thanks for opening the issue. We will take a look soon. Meanwhile, could you tell us what version of Ubuntu are you using and how are you obtaining Python (deadsnakes, main repo, pyenv...). Also is this when analysing a live process or a core file? |
Also, just to ensure we use what you already debugged: what's making your rodata section different than a regular binary? (It's not immediate clear from your comment) |
I am compiling Python from source myself with a crosstool targetting towards a non-distribution provided version of glibc. As such, I don't expect many people to be following the same process. I am not sure what what is resulting in this difference though, maybe because I use gold instead of ld? I was analyzing a core file while pointing to the same python binary that the core file was extracted from. I just recently found a workaround is to essentially disable the |
My suspicion here is that what's going on is that you have a first PT_LOAD segment that doesn't map to the start of the file. When the linker loads the file in memory, the sections (such as .rodata) don't matter anymore and the only thing the linker sees its LOAD segments. For this reason, we just need to find where the first LOAD segment (the mount point) it's in the file and correct by that (which we aren't doing at the time). To corroborate this, do you mind sending the output of readelf -a over the binary? |
(I cut out some sections that contain literally all of the Python symbols). We pass |
Ah there you go:
I will try to make a patch this week |
Yeah that's also my guess but I have seen this on the wild as well so I don't think it's unique of this situation |
Thanks for the quick help, I am hardly an ELF expert so ended up reading a lot of docs today to figure out why this was not working... |
Is there an existing issue for this?
Current Behavior
I have been trying to debug why
pystack
thinks I am using python version12.41
and it turns out that my python binary has a different layout. This problem seems to only occur (or at least I've only noticed thus far) when it attempts to find hte value ofPy_Version
. The version of python supplied by ubuntu has elf section forrodata
that looks like this (obtained withreadelf -S
).Mine looks like this:
Expected Behavior
The proper way to look up the address would be something like
<addr of Py_Version> - 0x00000000008741c0 + 004741c0
Since these values are the same in most python binaries, the issue would go unnoticed. I am not sure if this is some guarantee that the normal python build process makes or not, so this could also bite regular python versions later.
I was able to validate that the calculation above would work for my binary, where
0x0000000000ba2c68
is the address that pystack is attempting to look up.Steps To Reproduce
I am not sure how you would easily reproduce this issue as you'd need to produce a python binary that has the rodata addresses like the one in my example. If you are able to do that the issue reproduces very easily and all functionality of
pystack
will fail.Pystack Version
1.3.0
Python Version
3.11
Linux distribution
Ubuntu
Anything else?
No response
The text was updated successfully, but these errors were encountered: