-
Notifications
You must be signed in to change notification settings - Fork 489
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
What is the purpose of kernel_virtual_offset? Is set wrong for Linux. #1507
Comments
It was supposed to be the virtual address where the kernel lives. I would prefer it if the value were set right (assuming we know by that point). I'm not sure why it never got set properly, it doesn't look as though we used that value anywhere, so it should be safe to change it. I think when the kernel module is constructed, it's used as the offset for the module which means it might affect offsets returned for symbols from the module, just something to watch out for. Linux code may not have been asking for the relative address, so will just need some testing once it's put in place. |
I think probably I should work towards deprecating it. Since it's actually an attribute of the kernel (accessed through kernel.offset) rather than an attribute of the layer. You can have a layer without a kernel virtual offset (which is why it's optional, even though a lot of plugins just expected it to exist, see #1600 ). It'll require some plugin APIs changing to take a module name rather than a layer name and symbol name... |
I did eventually figure out that its used along with the ASLR shift ot get symbols correctly for Linux. |
Sure, but... it should probably be being stored and retrieved from the kernel module, rather than tagging it into the layer. The reason it lived there is because there didn't use to be the concept of a kernel module, only the layers, but now we have that, we should put it where it belongs (the kernel's |
@ikelos is this something needed for parity? I would need you to at least code up part of it to see what it should look like, if so. |
So, I don't know that I understand how it's being used in linux/mac land well enough. From what I can see, automagic sets it in linux and mac worlds at these locations:
But if the aslr_shift is 0, then they aren't likely to point to where the kernel module is loaded (which is what the variable was intended to hold) but instead to a shift value. There's only one linux plugin that uses that value, and it's kallsyms:
All the current windows usages (there's several) would need to change from:
to
Assuming that kernel was the |
I need to think of a way to deprecate the requirement from the Intel layer (it's optional, so most code should already cope with it not being present, but I'm fairly sure most won't), but I'd like to get linux/mac storing the right thing in the right place (they might already?) and have kallsyms use that (unless it really did need the ALSR shift, in which case we need to figure out how to expose that, but it's probably not something that's tagged against the layer, but more against the module or symbol table or something. |
@ikelos what is the purpose of
kernel_virtual_offset
outside of Windows? For example, Linux sets it here.. but sets it to the ASLR shift value, which doesn't make any sense:https://github.com/volatilityfoundation/volatility3/blob/develop/volatility3/framework/automagic/linux.py#L97
From grep'ing the code base it only looks like this value is used for Windows, not Linux or Mac.
The current Linux automagic is really rough and fails on many samples in my test set, so I am having to rewrite it anyway so I want to set that value correctly or just not set it if it isn't needed. I see that the Windows plugins all need the offset to do then symbol lookups, but we get that for free in a different way on Linux.. so maybe its not needed.
The text was updated successfully, but these errors were encountered: