Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 17395: /trunk/epan/: emem.c
Underrunning the first block will be caught by the guard page, so
prepending a canary shouldn't be necessary. Underrunning subsequent
blocks will be caught by the canary that follows the previous block.
That's how it's _supposed_ to work, at least...
Note that invalid reads won't be caught as long as they don't hit guard
pages. There are other situations that we may not catch, such as
dissectors re-using ep_allocated memory.
Maynard, Chris wrote:
> 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.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
