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

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

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

> "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.

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