Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!)

[Scott Long]

On Feb 4, 2014, at 3:09 PM, Garrett Wollman <wollman at csail.mit.edu> wrote:

> <<On Thu, 30 Jan 2014 17:33:42 -0700, "Kenneth D. Merry" <ken at freebsd.org> said:
> 
>> The fact that the redzone code doesn't expose any problems makes it more
>> likely that it is a problem other than a heap overflow.
> 
> So I built a new kernel with DEBUG_MEMGUARD.  When
> vm.memguard.desc="mps", everything works fine both through two
> load/unload cycles and statically compiled into the kernel.  When
> vm.memguard.desc is not set, instapanic as before.  (I'm trying
> memguard rather than redzone as it has much less of a performance
> impact, so I can start doing some of the performance testing I was
> originally intending to do.
> 
> Are there any debugging options that I could usefully enable that
> would show just what mps is doing when the fault happens?  I see that
> there are lots of tracing options but I don't know what would actually
> be useful.
> 

Try the patch at http://people.freebsd.org/~scottl/mps.memguard.diff

I haven’t even compile tested it, so hopefully any mistakes are easy to fix
and aren’t too embarrassing.  The target array is an obvious culprit since it’s
often indexed without bounds.  If this doesn’t fix it then I’ll have to think of
some other culprits.  Another next step would be to further divide and test
the M_MPT2 malloc allocation type.

Scott