Ethereal-dev: RE: [Ethereal-dev] Re: [Ethereal-cvs] rev 17395: /trunk/epan/: emem.c
Not a comment for the guard pages themselves, but more for the canaries
....
Will under-runs actually be caught by the canary if it's only appended
to the end of the allocated block? Should a canary be added to the
beginning of the allocated block as well as to the end in order to
ensure under-runs are caught? Something like:
+----+---+--------+---+---+--------+---+------+----+
| gp | c1| alloc1 | c1| c2| alloc2 | c2| ... | gp |
+----+---+--------+---+---+--------+---+------+----+
Because can't you have non-emem-allocated memory between the
emem-allocated chunks? Or is my understanding of how emem works
incorrect?
At the very least, shouldn't there be a canary before the alloc1 block,
or can we safely rely on the guard page to catch that?
- Chris
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Gerald Combs
Sent: Monday, February 27, 2006 4:12 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 17395: /trunk/epan/:
emem.c
I just checked in support for guard pages. Keep in mind that guard
pages are just that - entire pages of memory. They're too big to put
between allocations, so we still have to use canary values like so:
+----+--------+---+--------+---+--------+---+-------+----+
| gp | alloc1 | c | alloc2 | c | alloc3 | c | ... | gp |
+----+--------+---+--------+---+--------+---+-------+----+
("gp" = guard page, "allocn" = allocated memory, "c" = canary). Guard
pages will likely catch instances where the dissector runs away, writing
way past the beginning or end of an allocation. Most over- and
underruns should still be caught by canaries. The best way I've found
to debug such instances is to uncomment EP_DEBUG_FREE and SE_DEBUG_FREE
in emem.c, recompile, and run [t]ethereal under Valgrind.
It'd be nice if we could let Valgrind know about allocations directly,
but according to http://valgrind.org/help/projects.html this hasn't been
properly implemented yet.
BTW, can someone look over the guard page code and verify that it's
correct?
[snip]
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
