Re: LLVM--Low Level Virtual Machine--and Ada

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Duncan Sands" <baldrick@free.fr> 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