Mail Archives: djgpp/2001/06/30/15:00:08
> >This won't catch huge overruns, but if you write-protect the entire text
> >section you will at least prevent overwrite of executable code and catch
> >errors sooner with correct error messages.
>
> For non-self-modifying-code (and self-modifying is rare these days --
The problem is hand written assembler which put data values in the .text
section. In particular, exceptn.s stores some values for exceptions and
interrupts next to the code so it can be locked by DPMI in a single call.
(It also helps makes sure exceptions/tracebacks work or not - if you trash
the couple Kb where all this lives nothing works). My fault - I wrote the
first version around 7 years ago. I've always known this would need to be
fixed if we set .text to be read only - but until this recent thread noone
seemed to think it was worth the effort. There are probably a few other values
in other assembler modules also that would need to be changed.
If we locked all the .text section we would potentially break other modules
that get linked in that have been written that way over the years too.
So, it would probably be best to put the exception handlers and code needed
into their own section - which means linker script changes, etc. Not
impossible, but not worth my effort for the one in thousand program that
trashes the memory space such that the exception handler won't run. Since
most DPMI providers don't even support making the memory read only anyway -
the value becomes zero for many common environments (Windows).
Low effort fixes - setting bottom of stack uncommitted - this would
catch recursive programs that didn't jump down too much stack at once
and skip the uncommitted section.
- Raw text -