TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Tucker Taft <[log in to unmask]>
Reply To:
Tucker Taft <[log in to unmask]>
Date:
Thu, 6 Apr 2000 16:17:46 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (69 lines)
"Criley, Marc A" wrote:
>
> I made the following postings on comp.lang.ada to get some general feedback,
> and Britt Snodgrass subsequently suggested I repost them to Team Ada.
>
> First the original posting:
>
> --------------------------------------------------------------------
>
> To Ada to JBC compiler vendors:
>
> Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure
> Common Operating Environment (DII COE) Integration & Run-Time
> Specification (I&RTS) v4.0 states that "Developers shall not use
> compilers designed to convert code developed in other languages (e.g.,
> Ada, C++) to create Java byte-codes. This restriction is important
> because such compilers may inadvertently bypass intended Java security
> features."
>
> Is this a legitimate concern?

No.  The output of the Ada compiler is treated no more and no
less suspect than the output of any Java compiler (remember,
there are no "validated" Java compilers yet).

I know from experience that the Java virtual machine includes
a component called the "byte code verifer" and this is run over
any code that is downloaded from the web, and also by default
over local Java code.  The byte code verifier in conjunction
with the Java RTS enforces all of the Java security features.
A non-buggy Java compiler may give "early warning" of violations
of certain Java "security" features, but the byte-code verifier
doesn't rely on that in any way.

> I can kinda see how it might be, since
> for instance Java forbids things like uninitialized objects (though I
> vaguely recall some kind of exception to that), which Ada permits.  I
> suspect I could probably come up with some other potential problems if I
> dug into it.

Nope, there are no security holes associated with using an Ada=>JBC
compiler, or for that matter using a buggy Java=>JBC compiler.
The only security holes are those inside the byte-code verifier,
the byte-code interpreter, or the Java RTS.  Whether you start
from Java, byte-code assembler, Ada, or whatever, this has no
effect on security, and the holes that exist are unrelated to
the compiler you use.

For the specific example of uninitialized local variables, that is
detected by the byte code verifier, but the compiler (both Ada
and Java) will give early warning if you try to leave a local
uninitialized.

>
> If the Ada to JBC compilers do not introduce the security risks that the
> I&RTS warns about, some educating is clearly called for.

Education is called for.  Whether "learning" will occur as result
of the education is TBD.

>
> Marc A. Criley

-Tucker Taft  [log in to unmask]
--
-Tucker Taft   [log in to unmask]   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

ATOM RSS1 RSS2