Re: Partial Hardware Protection for Buffer Overrun Exploits

["Randy Brukardt" <randy@rrsoftware.com>]

Warren W. Gay VE3WWG wrote in message <3E9ED2E7.80807@cogeco.ca>...
>I can't say that I am familiar with this hardware, but I sense that
>you might misunderstand my suggested approach. I am _not_ suggesting
>in _this_ proposal that executed code must be in a read-only
>segment (text region), but that the new RETURN instruction only
>accept valid addresses in the read-only segments (ie. text region).


That's equivalent to saying that the stack not be marked as executable
code. And it shouldn't anyway, I think it is idiotic that any modern OS
uses a model with no separation of code and data.

Janus/Ada for the Pharlap DOS Extender always did this. The Intel
processor only allows Read-Execute and Read-Write access to segments
(but not both). The DOS Extender (and Windows and Linux do this too) get
around this 'limitation' by providing mirrored segment values that point
at the same memory. What our DOS Extender compiler did was to allocate
the real data area using an OS call, then replaced all of the writable
segment descriptors with the one from the allocation -- including the
stack. (That was a bit tricky!). Then, it was impossible to write the
code segment or execute the data segment without a trap. That caught
plenty of bugs in the implementation of the compiler.

This is such an obvious idea that it's getting implemented in BSD. I saw
this article yesterday:

http://news.com.com/2100-1002-996584.html

My only question is why they didn't do this years ago. The Intel
hardware has always supported it...

            Randy.