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?
LEGO wrote:
> Right... And there's no doubt g_error is more polite than g_assert. :-)
>
> BTW, I think that your proposal for guard edges would be much better.
> As we would abort while corrupting with a clean stack trace instead of
> exiting much after the prolem was (specially with se_alloc).
>
> On 2/24/06, Gerald Combs <gerald@xxxxxxxxxxxx> wrote:
>> I certainly hope so. Several dissectors use emem-allocated memory for
>> pointers and other sensitive data. If they get overwritten I'd like to
>> inform the user, then make a hasty exit.
>>
>> LEGO wrote:
>>> Doesn't g_error exit as well?
>>>
>>> On 2/24/06, gerald@xxxxxxxxxxxx <gerald@xxxxxxxxxxxx> wrote:
>>>> User: gerald
>>>> Date: 2006/02/23 05:12 PM
>>>>
>>>> Log:
>>>> Print an error when we detect memory corruption. Fix a typo in a comment.
>>>>
>>>> Directory: /trunk/epan/
>>>> Changes Path Action
>>>> +5 -5 emem.c Modified
>>>>
>>>>
>>>>
>>>> http://anonsvn.ethereal.com/viewcvs/viewcvs.py?rev=17395&view=rev
>>>> _______________________________________________
>>>> Ethereal-cvs mailing list
>>>> Ethereal-cvs@xxxxxxxxxxxx
>>>> http://www.ethereal.com/mailman/listinfo/ethereal-cvs
>>>>
>>>
>>> --
>>> This information is top security. When you have read it, destroy yourself.
>>> -- Marshall McLuhan
>>> _______________________________________________
>>> Ethereal-dev mailing list
>>> Ethereal-dev@xxxxxxxxxxxx
>>> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>> _______________________________________________
>> Ethereal-dev mailing list
>> Ethereal-dev@xxxxxxxxxxxx
>> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>>
>
>
> --
> This information is top security. When you have read it, destroy yourself.
> -- Marshall McLuhan
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev