X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: protecting program memory Date: Sun, 25 Mar 2007 23:27:27 CDT Organization: Rice University, Houston, TX Lines: 40 Message-ID: <46074baf.sandmann@clio.rice.edu> References: NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1174883985 7652 128.42.105.3 (26 Mar 2007 04:39:45 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: Mon, 26 Mar 2007 04:39:45 +0000 (UTC) X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > # 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. Correct. But CWSDPMI implements enough of the DPMI 1.0 specification that you can make pages readonly. This is the same API which is used to make the "null" page non-mapped to catch all references to null pointers. > 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 some non-clean parts of the libc which have writeable code sections, so you will need to identify those and keep them as writeable. If I remember correctly they are in the exception handling code and maybe the stub itself. I don't remember completely, but you should check for the mprotect() function. It's been a long time, but I remember supporting a memory allocation package which protected it's control structures and fencing it's allocated memory using these routines.