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!newsfeed2.dallas1.level3.net!news.level3.com!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 19:28:30 -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: pcls4.std.com 1185319711 5020 192.74.137.71 (24 Jul 2007 23:28:31 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 24 Jul 2007 23:28:31 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:WZAko+fWpsFWeScQ5cZ2ZZk7c6E= Xref: g2news2.google.com comp.lang.ada:1137 Date: 2007-07-24T19:28:30-04:00 List-Id: "Randy Brukardt" writes: > "Duncan Sands" wrote in message > news:mailman.6.1185176858.3834.comp.lang.ada@ada-france.org... >> Hi Bob, thanks for your informative reply. >> >> > Another problem is that some modern machines use DEP (which I think >> > stands for "data execution prevention" or something like that). DEP >> > means the operating system prevents writeable data from being executed >> > as code. The purpose is to prevent certain kinds of security holes >> > that are common in languages that don't do array-bounds checking. >> > But DEP prevents trampolines from working, so users have to turn >> > it off in order to run some Ada programs (such as the compiler). >> > It's a pain because users get some mysterious error message >> > when trampolines are used. >> >> 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. The need for DEP is really because we live in a C world. And DEP doesn't even solve the problem. > 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. >... 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. > 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! >...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. 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. - Bob