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: g2news2.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Tue, 29 Mar 2011 18:45:16 -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 1301442321 11323 69.95.181.76 (29 Mar 2011 23:45:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 29 Mar 2011 23:45:21 +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: g2news2.google.com comp.lang.ada:19561 Date: 2011-03-29T18:45:16-05:00 List-Id: "Shark8" wrote in message news:e927347b-4f90-471a-b574-878e655eba89@34g2000pru.googlegroups.com... On Mar 28, 8:32 pm, "Randy Brukardt" wrote: >> Not relevant to this discussion, but I think that's sad, as a lot of the >> security problems inherent in buffer overflows would have been avoided by >> simply keeping separate code and data segments. That would prevent code >> on >> the stack from being executed. (We found a lot of problems in Janus/Ada >> by >> keeping the code and data segments in our DOS Extender compilers >> completely >> separate; it's been quite a bit harder to find those problems on Windows >> or >> Unix systems that don't properly separate them.) The problem with >> segments >> is segments that are too small, not the basic idea. > >...but aren't segments, in 32-bit machines, capable of doing 4GB? Right. That's why it is sad that operating systems stopped using them when they moved to 32-bit. In the 16-bit systems, the segments could be too small, which made things messy to use, but that is much less of a problem for 32-bit segments. >But I see what you mean about data/code segment separation... though >it can also be a source of frustration if you want to do some >self-modifying >code. But that's actually a feature. To do self-modifying code, you have to ask the OS for a read-write-execute code/data segment. The vast majority of programs have no good reason for doing that, so they would have no way to execute injected code (presuming that the compiler run-time does not include unused APIs). That alone would have made programs safer, by blocking most of the avenues that buffer overflows could have been exploited. One could even imagine that using that API would require elevated permissions and signed executables (although I think that was not something that was worried about in 1990). Of course, recent OSes have been trying to graft this sort of security back on (breaking lots of code), but that all could have been avoided if the code and data had been truly separate in the first place. Randy.