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!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: LLVM--Low Level Virtual Machine--and Ada Date: Tue, 24 Jul 2007 22:00:59 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1184730995.862147.208590@g12g2000prg.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1185328860 20696 192.74.137.71 (25 Jul 2007 02:01:00 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 25 Jul 2007 02:01:00 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:ys1SNTMPFOUBFDI8rcfGgrXQO5I= Xref: g2news2.google.com comp.lang.ada:1147 Date: 2007-07-24T22:00:59-04:00 List-Id: "Randy Brukardt" writes: > "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. Agreed. >> 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. Well, maybe, but security issues invoke the "weakest link in the chain" problem. >... And remember > that even Ada programs have to call C code to access OS facilities and the > like. That's what I meant by, "we live in a C world." ;-) >> 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. Not sure what you mean by "extreme". A process may or may not have permission to read/write/execute certain pages of memory, and may or may not have permission to change its permisions... >> > 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. Correct. Ada itself does not require trampolines. So why use them? Well, I suppose it was an easy implementation. They could be got rid of, except in the cases of interface-to-C, and 'Unrestricted_Access. >> >...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. I don't get it (how displays help, here). If you have displays instead of static links, you need to pass display, or pointers to them. >...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. I agree, but that's how it works in gcc C -- you can pass a pointer to a nested function to another procedure, and that thing might save it in a global, and then call it later. It works, so long as the outer function is still active. I.e. it's unsafe. Ada prevents that sort of thing. >... 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 Right. >...(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. Not "screwed". It just means that 'Unrestricted_Access might need to use trampolines. The standard Ada features can avoid them. >... Still, I think GNAT should do what it can to avoid them; Agreed. > 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). It's acceptable, IMHO. >> 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). Trampolines are worse than thunks, efficiency-wise. But it's only in Ada 2005 that it started to matter much. - Bob