investigate issues in vadtree

[GoogleCodeExporter]

LabarumXP noticed (and I think I noticed a while ago and didn't log it) that 
vadtree when graphed with graphviz has incorrect node relationships (there are 
way too many parent nodes). This is just a reminder that we need to look into 
it. 

Original issue reported on code.google.com by michael.hale@gmail.com on 12 Apr 2012 at 1:00

[GoogleCodeExporter]

Hmmm, is there any more detail to this one?  I've run a couple of dot outputs 
of vadtree and haven't noticed any nodes with more than one parent.  Is there a 
public example image that exhibits this issue?

Original comment by mike.auty@gmail.com on 14 Apr 2012 at 3:06

[GoogleCodeExporter]

Not yet Mike, I haven't deep dived into it, just heard from AW that there was 
an issue. Give me a few and I'll gather some details and if an image isn't 
already public, I'll post one. 

Original comment by michael.hale@gmail.com on 14 Apr 2012 at 6:50

[GoogleCodeExporter]

Hey guys, I'm about to commit a fix for vadtree on 2003, 2008, vista, and 7 x32 
and x64. In short, our currently implementation only works on xp x86 ;-)

The trick is that on xp x86 the parent (vad.Parent) is a pointer to an MMVAD, 
but on all other systems, even xp x64, the parent (vad.u1.Parent) is a packed 
union with vad.u1.Balanced. when computing the address of a vad's parent, we 
didn't clear the bits in the packed union that were for the Balanced member, 
thus we were trying to dereference pointers like 0x8??????3 which isn't aligned 
and fails...resulting in parent being 0, which in turn results in like 100 
parent nodes in our tree. 

Original comment by michael.hale@gmail.com on 8 May 2012 at 10:03

[GoogleCodeExporter]

This issue was closed by revision r1680.

Original comment by michael.hale@gmail.com on 8 May 2012 at 10:09

• Changed state: Fixed

[GoogleCodeExporter]

Are packed unions a thing we're likely to run into often?  Is it possible to 
determine which bits are appropriate from the vtypes?  I'm trying to figure out 
whether it'll be worth building this into the vtype system, rather than 
requiring plugin developers to do the masking manually.  Basically, if we 
reckon four or more plugins will need to use packed unions, then it's probably 
worth trying to find some way of making it easy to specify (even if ultimately 
there isn't a way of doing it).  If it's a rare thing, then not worth the 
effort...

Original comment by mike.auty@gmail.com on 8 May 2012 at 10:28

[GoogleCodeExporter]

Hmm, I can't say we're likely to run into it often. This is the first time I've 
run into it with volatility, though some might consider _EX_FAST_REF a packed 
union - they are both attempts by Microsoft to reduce the size of their 
structures by storing extra values in lower bits of other values (usually 
pointers). In the case of _EX_FAST_REF, you could not determine the bits using 
vtypes. However, using vtypes might have been possible for _MMADDRESS_NODE.u1 
since it looks like this:

  '__unnamed_16a1' : [ 0x4, {
    'Balance' : [ 0x0, ['BitField', dict(start_bit = 0, end_bit = 2, native_type='long')]],
    'Parent' : [ 0x0, ['pointer', ['_MMADDRESS_NODE']]],
} ],

I'd personally not spend the time automating this kind of thing, but it might 
be a fun challenge ;-)

Original comment by michael.hale@gmail.com on 9 May 2012 at 3:09