Skip to content
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

Open
atcuno opened this issue Jan 2, 2025 · 7 comments
Open
Assignees

Comments

@atcuno
Copy link
Contributor

atcuno commented Jan 2, 2025

@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.

@ikelos
Copy link
Member

ikelos commented Jan 3, 2025

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.

@ikelos
Copy link
Member

ikelos commented Feb 2, 2025

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...

@atcuno
Copy link
Contributor Author

atcuno commented Feb 2, 2025

I did eventually figure out that its used along with the ASLR shift ot get symbols correctly for Linux.

@ikelos
Copy link
Member

ikelos commented Feb 2, 2025

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 module.offset). The symbol table can still have its shift as needed, it just has the variables stored in a more sensible place (and needs some of the plugins bringing in to line with the ModuleRequirement that most current plugins use).

@atcuno
Copy link
Contributor Author

atcuno commented Feb 15, 2025

@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.

@ikelos
Copy link
Member

ikelos commented Feb 15, 2025

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:

volatility3/framework/automagic/mac.py:                new_layer.config["kernel_virtual_offset"] = kaslr_shift
volatility3/framework/automagic/linux.py:                layer.config["kernel_virtual_offset"] = aslr_shift
volatility3/framework/automagic/linux.py:                context.config[join(config_path, "kernel_virtual_offset")] = aslr_shift

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:

volatility3/framework/symbols/linux/kallsyms.py:        address += layer.config["kernel_virtual_offset"]

All the current windows usages (there's several) would need to change from:

kvo = context.layers[layer_name].config.get("kernel_virtual_offset", None)

to

kvo = kernel.offset

Assuming that kernel was the ModuleRequirement they had...

@ikelos
Copy link
Member

ikelos commented Feb 15, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants