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

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccvec95qld.fsf@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...
...
> >> 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.