What is the purpose of kernel_virtual_offset? Is set wrong for Linux.

[atcuno]

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

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]

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]

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

[ikelos]

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]

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

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]

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]

So, at some point, we'd like to get everything in line, which means setting the offset correctly for modules (and then potentially providing a symbol_shift value to allow symbol requested through the table to shift appropriately). This will need somethinking about, because then raw symbol tables for windows and raw symbol tables from linux will differ (in that the former will be relative and the later absolute), but the idea is to provide consistency through the module interface (and that's why the offset should always strictly be the offset of the kernel). We might be able to tag the shift into the module, but it's not clear if that's useful data, given it should be baked into the offset... We can special case the modules for OSes, but the more different types we have the harder it'll all get to manage, so I'm trying to avoid that.

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 60 days since being marked as stale.