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-Thread: 103376,2cb1f0b6d642e1dc X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Wed, 30 Mar 2011 14:40:14 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1301514017 24268 69.95.181.76 (30 Mar 2011 19:40:17 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 30 Mar 2011 19:40:17 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news1.google.com comp.lang.ada:18611 Date: 2011-03-30T14:40:14-05:00 List-Id: "Robert A Duff" wrote in message news:wccei5o233l.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: > >> 99% of the time, executing data is a bug. Why allow it by default? > > Ah, I didn't realize you were mainly focused on that issue. > I agree 100% that executing data is usually a bug, and should > be prevented by default. > > But you don't need segments for that. Paging hardware can do it. > (Well, you don't need segments in hardware. The O.S. concocts > something like "segments" based on paging. And protects code.) True enough, but I was focused primarily on the existing capabilities of the 80386 (which is the CPU that most of the current OSes started on). This chip had segments with the "right" permissions, while the paging stuff had little permission control. (And no OS or OS extension that I know of in that time frame used that permission control.) Also, I think there is a (minor) advantage to separate code and data address spaces, in that makes it harder still to do something that fools the OS into executing data. If you have no executable access to the data address space, there is no possible bug that would allow data execution. In any event, this was completely obvious to me even back in the days of the DOS Extender. All of the DOS Extenders gave you a totally flat address space, but they all also had a way to get a new segment. So I had Janus/Ada create a stub data segment in the executable file, and the first thing the runtime did was create a new (full-size) data segment, moved the stack there, and removed all references to the writable code segment registers. This helped fix a lot of bugs, because wild execution trapped instantly, rather than running for quite a while before crashing. It's too bad I can't do that on Windows, because I have some problems that I've been unable to debug with wild code execution -- I haven't been able to identify where it goes wrong. Randy.