X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Newsgroups: comp.os.msdos.djgpp
From: John_W_Herman AT yahoo DOT com (John Herman)
Subject: Re: protecting program memory
References: <OF8FAF1ED8 DOT 483B1086-ON872572A7 DOT 0078F978-872572A7 DOT 007C4A14 AT seagate DOT com> <eu1u50$9ck$1 AT aioe DOT org>
X-Newsreader: News Xpress 2.01
Date: Sat, 24 Mar 2007 16:52:49 GMT
Lines: 57
Message-ID: <46054940$0$16714$4c368faf@roadrunner.com>
Organization: Road Runner High Speed Online http://www.rr.com
X-Complaints-To: abuse AT rr DOT com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

You might investigate bounds checking tools.  I've used Electric Fence but 
there are lots of others.  There are also some excellent commercial tools for 
this purpose.

In article <eu1u50$9ck$1 AT aioe DOT org>, "Rod Pemberton" <do_not_have AT bitfoad DOT cmm> 
wrote:
>
><Gordon DOT Schumacher AT seagate DOT com> wrote in message
>news:OF8FAF1ED8 DOT 483B1086-ON872572A7 DOT 0078F978-872572A7 DOT 007C4A14 AT seagate DOT com...
>>
>> tim DOT nicholson AT skyforcekent DOT com wrote on 23 Mar 2007 04:16:50
>> -0700:
>>
>> # Is there an easy way to protect the memory used to store the
>> # program op codes from a rogue memory write from within the
>> # application? I have a large (100,000+ line) DJGPP
>> # application which sometimes crashes with SIGILL - It would
>> # seem the program is cannibalizing itself! In order
>> # to find how this is happening, I would like to protect the
>> # entire block of memory that contains the application code
>> # so that an exception occurs at the point the corruption occurs
>> # rather than the point that the corrupted code is executed.
>> #
>> # I guest I need to make the memory block read only, but I am
>> # not sure how to do that.
>>
>> Not without DPMI 1.0, you can't.
>>
>> But here's an alternative: checksum the executable space.
>>
>> You can get a pointer to the beginning of code and its size
>> by applying some mild abuse of GCC and the linker map:
>>
>>    extern char*               _text  asm(".text");
>>    extern char*               _etext asm("etext");
>>    static char*               __my_progstart   = NULL;
>>    static size_t              __my_progsize    = 0;
>>    __my_progstart = (char*) &_text;
>>    __my_progsize = (&_etext - &_text) - sizeof(void*);
>>
>> There are any number of things that you can do now, armed
>> with that data!  (Look into instrumentation with GCC...)
>>
>
>Nice.  Thanks.
>
>More info for my Grub MB header into first 8k of .exe without a linker
>script problem...  Alternately, I was currently thinking about just
>destubbing the .exe's DPMI host and RM startup code, prepending an MB header
>using the same (DJ COFF?) 32-bit entry point as the DPMI host.
>
>
>Later, for a while anyway...,
>
>Rod Pemberton
>
>