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-21 09:58:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news.uunet.ca!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3EA41F8E.8030305@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.os.assembly Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits References: <3E9D8AB6.4090009@cogeco.ca> <3E9ED2E7.80807@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Apr 2003 12:42:54 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1050943376 198.96.223.163 (Mon, 21 Apr 2003 12:42:56 EDT) NNTP-Posting-Date: Mon, 21 Apr 2003 12:42:56 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:36334 Date: 2003-04-21T12:42:54-04:00 List-Id: Randy Brukardt wrote: > 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. For most of _my_ code, that is probably true. However, JVM types of processes may disagree. They need to be able to assemble code on the fly and then give them control. However, I think you could regulate this with some "per thread/process flag". > 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. I would have thought that Linux/FreeBSD/Windows would have been taking advantage of this already. Is it true that "text" is not read only there? What a waste if they make that RW(!) > 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 I don't think much of the "random placement" idea, though I supposed they are being forced to deal with a problem that should be fixed in hardware (IMHO). > My only question is why they didn't do this years ago. The Intel > hardware has always supported it... > > Randy. Yes, indeed. In fact, it might be useful to go one step further, and add an execute bit (I am under the impression Intel doesn't make this distinction). Then you could distinguish between RO constants and X code. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg