From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 115e50,63e8a95e8331225 X-Google-Attributes: gid115e50,public X-Google-Thread: 103376,63e8a95e8331225 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-17 16:21:45 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada,comp.os.assembly Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits Date: Thu, 17 Apr 2003 18:22:34 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3E9D8AB6.4090009@cogeco.ca> <3E9ED2E7.80807@cogeco.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Newsreader: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:36264 Date: 2003-04-17T18:22:34-05:00 List-Id: 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.