From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9803221531.AA14900@clio.rice.edu>
Subject: Re: Can the text section be made read-only?
To: eldredge AT ap DOT net (Nate Eldredge)
Date: Sun, 22 Mar 1998 09:31:00 -0600 (CST)
Cc: cssl AT geocities DOT com, djgpp-workers AT delorie DOT com
In-Reply-To: <199803220136.RAA16736@adit.ap.net> from "Nate Eldredge" at Mar 21, 98 05:36:16 pm
Content-Type: text
Precedence: bulk

> Is that as simple as just adding `.data' before them and `.text' after? It
> looks like it is (the code that locks them doesn't seem to care where they
> are), but I'm not sure.

I think the interrupt handler code should stay in .text.  I don't want 
anything like that even close to user data, which may overwrite it.

You need to lock the new data section also (in dpmiexcp.c I think) and thus
have labels to be able to compute the length of each properly.  Bill Currie's
suggestion of just adding all the locked stuff to a different section is
very attractive...

> How about the variable in `crt0.s': `_what_size_app_thinks_it_is'? I blindly
> submitted a patch to move that into .data some time ago, and I think it
> ended up in the alpha. Does it need to be locked? I can't tell from the source.

Does not need to be locked.  Only the keyboard interrupt handler (for CTRL-C
recognition) needs to be locked.

> Other than that, can we just do something like this in, say, crt1.c?
> 
> extern int etext asm("etext");
> 
> void __djgpp_protect_text_section(void)
> {
>    __djgpp_set_page_attributes((void *)0, ((unsigned)&etext) & ~4096, 1);
> }

The address (and thus length) needs to be corrected to avoid messing with the
null protection page (so (void *)(4096)...)

> and then call it if the appropriate crt0 flag is set?

Or not call it if the appropriate crt0 flag is set.  What should the default
be?

>  Will `text' always be the first section, and will it always start at 
> virtual address 0?

Should be first, but starts at 0x1000 not 0.

> I suppose this will cause some minimal code bloat, by forcing
> `__djgpp_set_page_attributes' to be linked, but AFAICT it's only about 2-300
> bytes.

Yep, the problem is those 20 new features at 300 bytes each become noticeable.
But it will allow more rigorous checking and better code.  Another idea which
I considered was to "no access" (like null page) the bottom page of the stack
which would catch many overruns.  Lots of nice features which could be added...