[addr] and [addrpad] on PAE

[volatilityfoundation]

[addr] and [addrpad] on PAE

[ikelos]

First off, a reminder that this outputting scheme was put in place as a stopgap for a proper plugin output format. I'm impressed that it's managed to survive this long still working. It required code changes to each plugin that used it originally, and unfortunately a proper fix looks like it would need the same...

Ok, so the difficulty we have is that only the address space knows whether it's PAE or nonPAE. At the moment, we can fudge whether it's a long (64-bit) address or a short (32-bit) one, based on what the user told us in the profile, because that's in the global config, but whilst the profile can differentiate between 32 and 64, it can't differentiate between PAE and nonPAE. By the time we get to the formatter, all we have is the profile (from the global config). We don't even have the values themselves, because we have to draw the header bar and know the widths of columns before we see the values. Without them, we've no address spaces, so no chance of determining whether it's PAE or not. If anyone else can think of a way of figuring out if the space is PAE from the information we have, do shout! So our options are:

a) leave it as is
b) always display 48-bit address, in case it's PAE
c) write custom detection code in individual plugins that can detect PAE and lengthen the address field when necessary.

I'd recommend b, but it might be disconcerting for 32-bit analysis to be given 6 byte addresses the top two of which are almost always 0. b is a two second fix, but if we decide to go for c, we'll need to figure out which plugins to apply it to and that will take a little more time. Let me know what people think would be best?

[iMHLv2]

Hmm, yeah b would be easiest, but I'm just concerned it will make the output of virtual addresses (and other values we print as hex) on 32-bit systems look unnecessarily expanded. What are your thoughts on preemptively "fixing" this in 3.0? I think I would be OK with option a (leaving it as-is) now if we know a solution would be available in 3.0. For example, maybe a way to ensure the formatting code can easily access the AS/Profile?

[ikelos]

Well, in version 3 you'll be handed a whole table of data at once in a standard layout, so you won't have to parse it line by line, or know how you're going to lay it out before you've got all the data in front of you. There's now no reason to convert the objects from what they are (addresses), which should carry a reference to the original translation layer (address space) they came from, so that should be ok. Also, given we have all the values to begin with, we can just run through them and identify the maximum necessary length and 0 pad to that, so there's multiple ways of ensuring everything will come out aligned properly in version 3.0...

[iMHLv2]

OK, I'm fine with leaving it as is for now then.

[iMHLv2]

Marking as "wontfix"