general mudflap question

general mudflap question

[Eyal Lebedinsky]

Now that I am starting to follow up on violation  reports, I still
find myself unable to reconcile the information in the log with
the source code. It is probably time for me to understand better
the capabilities of the mudflap system.

I am now tracking a report that seems to come and go as I add
debug printing. It also moves about as I change the value of
-crumple-zone. This feels very much like a classic stack
overwrite and I am trying to understand how effective mudflap
is expected to be in detecting this.

If every pointer is checked then is it not the case that this
should not happen? OK, where can a breach take place?
	- in external code (libc etc.)
	- where else?

Naturally, at this point I am running non-threaded programs
only. And I should make it clear that so far more of the reports
are confirmed as problems in my code rather than misreports
my mudflap.

So, in short, I am asking:
	What is the scope of mudflap? What is the limit of
	its ability to detect violations?


And for some light entertainment I will now offer a specific
question that should demonstrate the limits of my current
understanding of the situation...

First the report:
=================
*******
mudflap violation 1 (check/read): time=1049877825.828932 ptr=09a4dfe8
size=8 pc=409c4086 location=`queue.c:421 (skqupt)'
      /home/eyal/a3mfn/bin/libssaiok.so(skqupt+0x1a0) [0x409c4086]
{queue.c:421}
      /home/eyal/a3mfn/bin/libssaiok.so [0x40a63d83] {sort.c:1443}
      /home/eyal/a3mfn/bin/libssaiok.so(skx094+0x4f3b) [0x40a7fb13]
{sort.c:2183}
      /home/eyal/a3mfn/bin/libssan3tb.so [0x4020742e] {Could not resolve
symbol}
      /home/eyal/a3mfn/bin/libssan3tb.so(n3gn21+0xbb0) [0x40209fb9]
{geneln.c:3322}
      /home/eyal/a3mfn/bin/testbed [0x80b50e2] {ssalm.c:2665}
      /home/eyal/a3mfn/bin/testbed [0x80d12df] {ssalm.c:4246}
      /home/eyal/a3mfn/bin/testbed [0x80dda46] {ssalm.c:4797}
      /home/eyal/a3mfn/bin/testbed(salmdt+0xd83) [0x80e0004]
{ssalm.c:4971}
      /home/eyal/a3mfn/bin/testbed [0x8061ad3] {testbed.c:3516}
      /home/eyal/a3mfn/bin/testbed [0x8065e95] {testbed.c:4105}
      /home/eyal/a3mfn/bin/libssaiok.so(skmain+0xecf) [0x409aff08]
{main.c:1041}
      /home/eyal/a3mfn/bin/testbed(main+0x4e9) [0x8064309]
{testbed.c:3850}
      /lib/libc.so.6(__libc_start_main+0xa4) [0x40b74914] {no debugging
symbols found)...(gdb}
      /home/eyal/a3mfn/bin/testbed(free+0x31) [0x804ab81] {Could not
resolve symbol}
Nearby object 1: checked region begins 0B into and ends 7B into
mudflap object 096d0788: name=`malloc region'
bounds=[09a4dfe8,09a4e04f] size=104 area=heap check=1r/0w liveness=1
watching=0
alloc time=1049877825.826980 pc=40b48f42

Looking up the code I see these snippets:
=========================================

struct ssa_queue {
        long            n;
        long            flags;
        ...
};
...

skqupt()
{
	struct ssa_queue	*q;
	...
421:	if (!(SSA_QUEUE_NO_LOCKING & q->flags) &&
422:		SSARC_BAD (rc = ssa_mutex_lock (q->mutex))) {


[the proliferation os 'ssa' in the code is related to the company
name and not to tree-ssa, which is just a happy coincidence]

Here I see that a violation is discovered in accessing 'q->flags'. I
verified it by adding this line just before line 421

	if (0 == q->flags)
		rc = 1;

and surely an identical report was generated. While I am rather sure
that
the item in question was initialised (my problem to track it) my actual
question is about the 'size=8' in the first line. The memory area in use
here is 4 bytes long (actually confirmed), so what gives?

TIA

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

Re: general mudflap question

[Frank Ch. Eigler]

Eyal Lebedinsky <eyal@eyal.emu.id.au> writes:

> [...]  I am now tracking a report that seems to come and go as I add
> debug printing. It also moves about as I change the value of
> -crumple-zone. This feels very much like a classic stack overwrite
> [...]  If every pointer is checked then is it not the case that this
> should not happen? [...]

That's right, within instrumented modules.  One limiting factor is the
availability of sufficient wrapper functions in libmudflap to let you
turn off the heuristics that make the system more permissive.
Uninstrumented routines like fread(), scanf(), gets() etc. all need
little wrappers in libmudflap to check their given pointers.  (Or
perhaps you could make yourself an entirely mudflap-instrumented
executable, without those pesky uninstrumented system libraries).


> And for some light entertainment I will now offer a specific
> question that should demonstrate the limits of my current
> understanding of the situation...
> 
> [...]
> *******
> mudflap violation 1 (check/read): time=1049877825.828932 ptr=09a4dfe8
> size=8 pc=409c4086 location=`queue.c:421 (skqupt)'
> [...]
> Nearby object 1: checked region begins 0B into and ends 7B into
> mudflap object 096d0788: name=`malloc region'
> bounds=[09a4dfe8,09a4e04f] size=104 area=heap check=1r/0w liveness=1
> watching=0
> alloc time=1049877825.826980 pc=40b48f42 [...]

This is the classic "uninitialized heap read" error we've discussed
several times.  The piece "area=heap check=1r/0w" means that this
object is on the heap but hasn't been written to.  (There is no
"dealloc" record, so this object is still alive, and the bounds are
okay too.)


> [...] my actual question is about the 'size=8' in the first
> line. The memory area in use here is 4 bytes long (actually
> confirmed), so what gives?

The mudflap instrumentation handles ptr->field checks specially, in
order to increase the likelihood of a hit in the lookup cache (which
is based on the base address only).  Instead of checking the interval
   & ptr->field ... ((char *) & ptr->field)+sizeof(ptr->field)-1
it checks a region starting at the plain pointer, to include all
prior fields too:
   ptr          ... ((char *) & ptr->field)+sizeof(ptr->field)-1

It may be that, if a more thorough initialization checking model is
later adopted in libmudflap, this optimization would need to go away.


You're getting into this stuff deeply enough for me to volunteer you
to review my draft paper for the GCC Summit :-).  It goes into some
detail about the mechanisms.


- FChE