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,b1f4420d01b2c4eb X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: LLVM--Low Level Virtual Machine--and Ada Date: Tue, 24 Jul 2007 19:39:26 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1184730995.862147.208590@g12g2000prg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1185323827 19985 69.95.181.76 (25 Jul 2007 00:37:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 25 Jul 2007 00:37:07 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:1144 Date: 2007-07-24T19:39:26-05:00 List-Id: "Robert A Duff" wrote in message news:wccvec95qld.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: > > > "Duncan Sands" wrote in message > > news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... ... > >> I'm not sure that this is a problem anymore: gcc uses a bunch of tricks > >> (eg: setting a flag on the program that notes it runs code on the stack) > >> to inform the operating system that the trampoline is kosher IIRC. That > >> said, I haven't tried to implement any of this in LLVM yet, which is also > >> why I'm vague on the details. > > > > That would be bad, as it would effectively turn of DEP for LLVM programs. > > These error detections are critically needed and turning them off just means > > you have buggy software that you can't/won't fix and that you're willing to > > remain part of the problem. > > Are you saying that executable data necessarily means the program is > buggy? If so, I don't agree. Trampolines are not bugs. They're slow. > Turning off DEP might expose _other_ bugs that cause security holes, but > those can be detected/prevented by array-bounds checking and the like. No, but I am saying that the vast majority of programs have no need for executable data. Which includes virtually all Ada programs, and it is bad to be turning off things which protects the program from bugs. > The need for DEP is really because we live in a C world. > And DEP doesn't even solve the problem. Of course it doesn't "solve" the problem, but it surely helps. And remember that even Ada programs have to call C code to access OS facilities and the like. Probably 50% of the bugs (and by far the worst ones) are in those interfaces, where the checking of Ada is no help. (And another 10% is compiler bugs that would have been detected by DEP; overwriting the return address of something is probably the most common symptom of compiler bugs that I have to track down. That may be because those are the hardest to find...) > > Honestly, I never understood why programs *ever* needed to execute > > permission on stack and data. > > There are several legitimate reasons why a program might want to execute > data. For example, consider a JIT compiler. Sure, but how many people are writing JIT compilers or overlay managers so they can get 2 megabytes of compiler code to execute on a 640K MS-DOS machine?? Hardly anyone, and people who need to do such things should be put through extreme hoops before being allowed to do so. (I'd suggest that they be required to write all of the JIT code in SPARC or a similar proof system, except that SPARC won't allow such dymamic things -- it's major failing IMHO.) > >... When we did our first 32-bit compilers, I kept > > those segments completely separate and was dismayed to find out that we > > couldn't set the permissions on the segments to actually match the uses (and > > thus detect bugs earlier). I managed to get the DOS extender versions > > sort-of-right by discarding the overlapping writable segments given to us by > > the OS and creating new non-overlapping ones for the data and stack. But > > neither Unix nor Windows provided anything that helped at all. I find it > > bizarre to find people deciding to apply the obvious technique of least > > privilege nearly 20 years later - what the heck have they been doing in the > > mean time? (Not caring if software is correct is one obvious answer...) > > I agree with you about "least privilege". To me, that means that > writeable stack/data areas should be no-execute by default. But a > program should be allowed to change that. Yes, possibly only with extreme permission. > > Janus/Ada has never used any executable data/stack in its 32-bit versions; > > such code would save no more than a clock cycle or two (out of hundreds or > > thousands) and as such could not be significant. > > On the contrary, trampolines do not save a clock cycle or two -- they > are horribly slow! Then why use them for Ada? Ada surely doesn't require them. > >...We use compiler-generated > > thunks rather than run-time generated trampolines, and I'm not sure why > > anyone would use the latter (given that they increase the exploitability of > > a program). Most be something I don't understand... > > Here's the reason for trampolines: > > The gcc dialect of C allows nested functions (unlike standard C). > > They wanted to allow pointers to these functions. > > They wanted to make those pointers fit in one machine word, > for two reasons: > > Some C programs might assume a pointer-to-function has that > representation (a single address -- of code). > > Programs that obey the standard (i.e. do not nest functions) should > not pay extra (no distributed overhead). > > A pointer-to-nested function needs access to the function's environment, > and the only way to do that, while keeping such a pointer in a single > word, is trampolines. That's not quite true, as the use of displays rather than static links would allow up-level access without any fat pointers. Although they might have wanted non-nested access, for which that wouldn't work. (Non-nested access shouldn't work IMHO, because of the significant risk that the stack frames no longer exist when the routine is called. That's the reason the anonymous access-to-subprogram parameters can't be converted to other kinds of access-to-subprogram.) In any case, Ada has restrictions such that these aren't needed for most access-to-subprograms, and fat pointers are fine for anonymous access-to-subprogram parameters (because you can't give these a convention and thus they don't need to be interoperable with C or anything else). GNAT is probably screwed though, because of the mistake of 'Unrestricted_Access for subprograms. Still, I think GNAT should do what it can to avoid them; most Ada access-to-subprogram types don't need them (although you would have to insist on having convention C on those types that are intended for interface use; perhaps that would be unacceptable). > Trampolines are not efficient! Because after writing the code, the > instruction cache needs to be flushed before calling the thing -- that > is expensive on modern machines. True. Thunks have similar issues in that the address of the thing isn't known before the call (so there is a pipeline stall), but at least we don't have to flush the cache. And there sometimes is the possibility of in-lining the call (something we don't currently do, but it is on the radar). Randy.