Compiling gnat into gcc-2.8.0

Compiling gnat into gcc-2.8.0

[Kevin Taylor]

I'm sure this has been discussed a billion times, but can someone point
me to some decent instructions on how to compile gnat into gcc?

I realize it has to be built at the same time as gcc, however, in the
directions I received with the gnat distribution, I need to already have
a version of gcc with ada support in order to compile gcc with ada
support...?

That doesn't make much sense, and I figure there's a way to do it from
scratch.

Thanks in advance.

-- 
  ..................................  .........................
 .                                  ..                         ..
. "If you take cranberries and stew ..      Kevin Taylor        ..
.. them like applesauce, it tastes ..     Systems Integrator     ..
 ..  much more like prunes than   ..                             ..
 ..   rhubarb does."            ...                              ..
  ..                            ..       Towson  University     ..
   ...    - Groucho Marx      ... Computing & Network Services .. 
     ..	                      ..                              ..
      ........................  ..............................

Re: Compiling gnat into gcc-2.8.0

[Simon Wright]

Kevin Taylor <ktaylor@towson.edu> writes:

> I'm sure this has been discussed a billion times, but can someone point
> me to some decent instructions on how to compile gnat into gcc?
> 
> I realize it has to be built at the same time as gcc, however, in the
> directions I received with the gnat distribution, I need to already have
> a version of gcc with ada support in order to compile gcc with ada
> support...?
> 
> That doesn't make much sense, and I figure there's a way to do it from
> scratch.

Why would you not believe the instructions?! you do indeed need to
start from a binary distribution (cs.ny.edu:/pub/gnat I think, or
mirrors)

Re: Compiling gnat into gcc-2.8.0

[Stephen Leake]

Kevin Taylor wrote:
> 
> I'm sure this has been discussed a billion times, but can someone point
> me to some decent instructions on how to compile gnat into gcc?
> 
> I realize it has to be built at the same time as gcc, however, in the
> directions I received with the gnat distribution, I need to already have
> a version of gcc with ada support in order to compile gcc with ada
> support...?
> 
> That doesn't make much sense, and I figure there's a way to do it from
> scratch.

Yes, this is correct. In the same way, you need a compiler with C
support before you can compile gcc to provide C support.

The difference is that a lot of systems come with a C compiler. Consider
installing gcc from sources on a vanilla Windows box, and you'll
appreciate the issues better.

You need a machine for which there is a binary distribution of GNAT.
Then you can cross-compile GNAT for your machine. From then on, you can
compile GNAT from source for each new release.

Another difference between gcc C and GNAT is that gcc C was deliberately
designed to compile with lots of different C compilers, while GNAT can
only be compiled with GNAT (not ObjectAda or any other Ada compiler).
This is because the internal compiler code relies on GNAT-specific
attributes (and there are probably other reasons). I doubt this will
change in the future (don't fix what aint broke), but as other Ada
compilers gain a wider distribution, it might be nice.

-- 
- Stephe

Re: Compiling gnat into gcc-2.8.0

[Robert Dewar]

Stephe says

<<Another difference between gcc C and GNAT is that gcc C was deliberately
designed to compile with lots of different C compilers, while GNAT can
only be compiled with GNAT (not ObjectAda or any other Ada compiler).
This is because the internal compiler code relies on GNAT-specific
attributes (and there are probably other reasons). I doubt this will
change in the future (don't fix what aint broke), but as other Ada
compilers gain a wider distribution, it might be nice.
>>

It would be *quite* a difficult project to make GNAT compilable with other
than GNAT, and does not seem particularly useful. Even if you had a machine
where some other Ada 95 compiler was available, and not GNAT (I know of
no such cases currently), then you would probably find it much easier to
do a cross-build than struggle with the incompatibilities. For example,
the use of Unrestricted_Access is definitely important at some points,
as is the exact conventions for external names.

Remember that GNAT is much more than just an Ada program, it is an Ada
and C program with intimate connections between the Ada and C, and the
code definitely makes use of the fact that it knows that the Ada and
C compilers are compatible.

If one could not rely on this, then you would have to use Interfaces.C
junk between the various pieces of the compiler, which would obfuscate
large chunks of the code, and slow things down.

There are *many* other reasons why this would be hard to do.

Re: Compiling gnat into gcc-2.8.0

[Robert Dewar]

Simon says

<<Why would you not believe the instructions?! you do indeed need to
start from a binary distribution (cs.ny.edu:/pub/gnat I think, or
mirrors)
>>

It is our experience that a lot of GNAT installation problems come from
people not believing some step in the directions is necessary :-)

Re: Compiling gnat into gcc-2.8.0

[Robert Dewar]

Larry says

<<If I were an ACT customer, I would prefer the first priority be to sign
CDROms distributed to paying customers (or is that done already?).
>>

Most of our customers prefer to use a secure FTP connection to obtain
the software, but we do provide for the possibility of distribution on 
CD ROM, and the officially validated version is available only on CD ROM
for an extra charge.

Re: Compiling gnat into gcc-2.8.0

[Markus Kuhn]

Stephen Leake wrote:
> Another difference between gcc C and GNAT is that gcc C was deliberately
> designed to compile with lots of different C compilers, while GNAT can
> only be compiled with GNAT (not ObjectAda or any other Ada compiler).

Paranoids will point out that this can be seen as a security problem
of gnat as it prevents source code review of the compiler. Read
Ken Thompson's legendary "Reflections on trusting trust" ACM
Turing award lecture if you do not understand why this is so:

  http://www1.acm.org:81/classics/sep95/

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Compiling gnat into gcc-2.8.0

[Richard Kenner]

In article <34F68913.2FF865DA@cl.cam.ac.uk> Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:
>Paranoids will point out that this can be seen as a security problem
>of gnat as it prevents source code review of the compiler. Read
>Ken Thompson's legendary "Reflections on trusting trust" ACM
>Turing award lecture if you do not understand why this is so.

Only if you rewrite /bin/login in Ada and compile it with GNAT. ;-)

Re: Compiling gnat into gcc-2.8.0

[Robert Dewar]

Markus says

<<Paranoids will point out that this can be seen as a security problem
of gnat as it prevents source code review of the compiler. Read
Ken Thompson's legendary "Reflections on trusting trust" ACM
Turing award lecture if you do not understand why this is so:

>>

Amusing, but inaccurate. There are many ways to review the code of GNAT
at this level of paranoia. For example, you can use objdump to look at 
the generated code interspersed with source. Another path would be to
entirely reconstruct the bootstrap path of GNAT from version 1.00 which
was bootstrapped with Alsys Ada.

Of course Alsys Ada, being a black box proprietary product, as are almost
all other Ada compilers, is quite inpenetrable to such validation, and
all Ken Thompson's entertaining constructions show is that a compiler
that is distributed in source form, by going to really heroic methods,
could manage to duplicate the same kind of duplicity that is absolutely
trivial to install in a proprietary product!

Of course, going back to the original, the idea that source code review
is ever adequate on its own if you are operating at this level of distrust
is completely bogus. Never mind far-fetched fantasy's of the KT style,
a more realistic concern is whether there is some accidental case in which
the compiler generates incorrect code for itself, and that due to some
horrible stroke of bad luck, this incorrect code is somehow risky.

If you are indeed operating at this level of paranoia, then the only
resort for any program is to review the object code line by line. The
fact that with GNAT you have the sources makes this possible, though
certainly expensive, and unlikely to be worthwhile.

Once again, with a proprietary product it would be out of the question to
review hundreds of thousands of lines of object code without reference to
the source code, so the free software approach has significant advantages,
even in this kind of environment.

Actually, probably if you even wanted to *consider* a validation at this
level it would be easier to modify GNAT so it could be compiled by some
other Ada 95 compiler, if for some reason that increases your confidence.
I noted this was a very hard task, but it is easy compared to doing line
by line object verification of a complete compiler.

It is interesting that I have occasionally run into a piece of FUD that
holds that somehow software is more susceptible to subversion if it is
available in source form.

There is of course no technical basis for such a claim. It probably stems
from the concern that if the sources are available, then anyone can modify
them. This is of course true, and there is no doubt that getting a version
of GNAT that has been modified by person or persons unknown, or may have
been modified in such a way, is potentially risky. We always warn people
that one of the issues in using the public version is that there is no
guarantee that we can provide that what you get corresponds to what we
initially distributed. It is most unlikely that anyone would have tampered
with the public distribution, but it is entirely out of our control.

One of the things that our customers obtain by buying support is the knowledge
that they are getting exactly the version that we guarantee matches our
very carefully controlled sources. This is of course the same guarantee that
you get when you buy a proprietary product. In this respect there is very
little difference between buying GNAT support and buying a proprietary
compiler.

The difference comes in to play when using the unsupported public version.
I am occasionally surprised to find serious projects using this version. For
my own taste I would never use unsupported software for any serious project
(by the way, I regard GNAT development itself as a serious project, and I
never permit any unsupported freeware or shareware on my own machine :-)
But of course this is a decision that an individual project needs to make
for itself.

Robert Dewar
Ada Core Technologies

Re: Compiling gnat into gcc-2.8.0

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 
> There is of course no technical basis for such a claim. It probably stems
> from the concern that if the sources are available, then anyone can modify
> them. This is of course true, and there is no doubt that getting a version
> of GNAT that has been modified by person or persons unknown, or may have
> been modified in such a way, is potentially risky. We always warn people
> that one of the issues in using the public version is that there is no
> guarantee that we can provide that what you get corresponds to what we
> initially distributed. It is most unlikely that anyone would have tampered
> with the public distribution, but it is entirely out of our control.

One way around this would be if ACT would publish PGP signatures of the
binary and source tar balls of the public gnat releases. Of course there
is still a lower risk that someone changes the signatures, but assuming
the web of trust works and that the signatures are widely published (e.g.
posted to Usenet etc.) this is a rather save choice.

-A.

Re: Compiling gnat into gcc-2.8.0

[Larry Kilgallen]

In article <m3yayxgl71.fsf@fred.muc.de>, Andi Kleen <ak@muc.de> writes:
> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
>> 
>> There is of course no technical basis for such a claim. It probably stems
>> from the concern that if the sources are available, then anyone can modify
>> them. This is of course true, and there is no doubt that getting a version
>> of GNAT that has been modified by person or persons unknown, or may have
>> been modified in such a way, is potentially risky. We always warn people
>> that one of the issues in using the public version is that there is no
>> guarantee that we can provide that what you get corresponds to what we
>> initially distributed. It is most unlikely that anyone would have tampered
>> with the public distribution, but it is entirely out of our control.
> 
> One way around this would be if ACT would publish PGP signatures of the
> binary and source tar balls of the public gnat releases. Of course there
> is still a lower risk that someone changes the signatures, but assuming
> the web of trust works and that the signatures are widely published (e.g.
> posted to Usenet etc.) this is a rather save choice.

If I were an ACT customer, I would prefer the first priority be to sign
CDROms distributed to paying customers (or is that done already?).

Some of the paranoid would want the signature to be hierarchy-based
and tied to a root from GTE or Verisign rather than the "Web of Trust"
method of PGP.  The nice thing about digital signatures, however, is that
you can sign the same thing several times to satisfy various constituencies.

Larry Kilgallen

Re: Trusting GNAT for security software

[Markus Kuhn]

Richard Kenner wrote:
> In article <34F68913.2FF865DA@cl.cam.ac.uk> Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:
> [gnat can only be bootstraped with gnat]
> >Paranoids will point out that this can be seen as a security problem
> >of gnat as it prevents source code review of the compiler. Read
> >Ken Thompson's legendary "Reflections on trusting trust" ACM
> >Turing award lecture if you do not understand why this is so.
> > http://www1.acm.org:81/classics/sep95/
> Only if you rewrite /bin/login in Ada and compile it with GNAT. ;-)

Actually, I am mostly interested in Ada, because I think it is a
language very suitable for security applications. Ada should
make an ITSEC E6 security evaluation significantly easier than a
language such as C and C++. I intend to use Ada to write cryptographic
access control software at least as security relevant as login or
PGP.

I know the following is paranoid, so consider it more as an
intellectual exercise than as a real concern. GNAT was financed
by the DoD, the same institution that operates NSA, an organization
well known for tampering with the production of cryptographic
systems all over the world to leave backdoors for their access.
Now if I ship my security software in Ada source code to allow
users to evaluate and trust it at a very high level, then what
real trust do I get if I compile this carefully scrutinized
backdoor free paranoid's dream softare with a compiler that I
can only bootstrap with a binary from a single DoD related source.

The practical precausion a paranoid can make is to archive now a
gnat binary version before publication of the security application
and then bootstrap all further new gnat releases with this old
release. This assumes that a Trojan Horse in gnat has to be built
into the binary distribution in with knowledge of the code that it
is supposed to affect, so if the bootstrap starts with an old
binary then Trojan's as described by Ken Tompson can be made
impractical.

Another idea would be that other compiler vendors make their
products sufficiently gcc compatible to allow GNAT bootstrapping
with their compilers.

Tampering with software by tampering with a compiler is in practice
rather easy. For instance, I only have to modify four bytes in
the Linux Netscape Navigator binary in order to build a backdoor
into its cryptographic protection facilities.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Trusting GNAT for security software

[Robert Dewar]

Marcus syas

<<I know the following is paranoid, so consider it more as an
intellectual exercise than as a real concern. GNAT was financed
by the DoD, the same institution that operates NSA, an organization
well known for tampering with the production of cryptographic
systems all over the world to leave backdoors for their access.
Now if I ship my security software in Ada source code to allow
users to evaluate and trust it at a very high level, then what
real trust do I get if I compile this carefully scrutinized
backdoor free paranoid's dream softare with a compiler that I
can only bootstrap with a binary from a single DoD related source.

>>


YOu obviously know little about the way in which university projects
are financed. Yes, the funds came from the DoD, but the DoD had ZERO
control over the project. NYU will not accept any kind of restrictions
on such projects. Early on, when we were working on Ada/Ed, NYU told
the US Army that it would turn down $1 million, rather than accept
a provision that publications had to be submitted to the Army for
preapproval. The Army suggested leaving in the presubmission and
removing the preapproval, but NYU said, no, remove the clause 
completely or take your money somewhere else. They removed it :-)

Actually I think a university project, particularly one working with
openly available sources, would be extremely hard to subvert in the manner
that Marcus' paranoid thinking suggests. Many students had full access to
every bit of information throughtout the development.

Actually an interesting bit of archeological data is that we have the
complete history of the GNAT project in terms of source development.
The semantics processing for chapter 3 is now at version 1145, and
you can look at all 1,144 previous versions, going back to the days
when we bootstrapped with Alsys.

As I said earlier, it always amuses me when people hypothesize that
free software is somehow especially subject to intrusion of this kind,
when in fact the exact opposite is true. There are freely distributed
Ada compilers being copied across the net now which are entirely
proprietary and you have no way of knowing what is inside them. Even
there I think the probability of any kind of deliberate Trojan horse
etc is very small, but note that in areas other than compilers there
have been concerns with proprietary software, e.g. Microsoft collecting
system information surreptitiously during installation, and various Web
sites installing cookies of dubious recipe. So these kind of concerns
are certainly not entirely frivolous.

I think the general recommendations here are to make sure you are dealing
with a reputable company and to be a little hesitant in using freeware,
shareware, or other unsupported software on critical projects. One thing
that is a bit worrisome is to see large critical porojects using unsupported
software, and that does happen sometimes. Actually the larger risk is simply
running into problems, rather than deliberate subversions.

Finally, as I noted in earlier mail, you can if you like examine GNAT
relatively easily at the code level to ensure absolutely that the code
generated is what is expected. The only way to protect a Ken Tompson type
Trojan Horse would be to enlist a huge suite of tools, both proprietary
and free software in the conspiracy, and *that* is getting a little 
far-fetched, even for conspiracy buffs :-)

Robert Dewar
Ada Core Technologies

Re: Trusting GNAT for security software

[Larry Kilgallen]

In article <dewar.888758710@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Marcus says

> Now if I ship my security software in Ada source code to allow
> users to evaluate and trust it at a very high level, then what
> real trust do I get if I compile this carefully scrutinized
> backdoor free paranoid's dream softare with a compiler that I
> can only bootstrap with a binary from a single DoD related source.

Well just because GNAT is written to rely on GNAT-specific features,
that doesn't mean your security software should be that way.  In fact,
I would be quite suspicious of a security product delivered in source
form allegedly for reasons of security if the instructions were that
I had to use a particular compiler even though it was written in an
internationally standardized language.

Robert says:

> YOu obviously know little about the way in which university projects
> are financed. Yes, the funds came from the DoD, but the DoD had ZERO
> control over the project.

This really is only of concern to those outside the US.  Those who pay
taxes to support the DoD know they are not that organized :-).

> Actually I think a university project, particularly one working with
> openly available sources, would be extremely hard to subvert in the manner
> that Marcus' paranoid thinking suggests. Many students had full access to
> every bit of information throughtout the development.

But those involved in security work are supposed to think paranoid.
If you don't have a list of possible attacks against which you do not
have a provable defense, then you haven't thought hard enough.  AMD
might have a special circuit inside their chips that recognizes code
generated by GNAT and if it finds it is doing triple-DES squirrels
away the key in a secret register.  One doesn't have to think a long
time about such attacks, but realizing what is possible is important
for realizing what is probable.  When some folks did this for Netscape
Navigatory they came up with "what if they used a crude random number
generator" and bingo, there was a vulnerability.

> As I said earlier, it always amuses me when people hypothesize that
> free software is somehow especially subject to intrusion of this kind,
> when in fact the exact opposite is true.

I don't think people theorize this any more about free software than
commercial software, nor any less.  With sufficient funding I could
set up higher bandwidth "mirror" sites for GNAT distribution, and
lacking signatures who would know if I had tampered?  Initially
someone would compare, but eventually they would grow tired.

On the other hand, I could use the same funding to become a "distributor"
of Microsoft software, giving them their full royalties but sending modified
CD-ROMs to the unwitting customers who would not know that I had inserted
bugs in the software.  Microsoft would get a reputation for buggy software.
Who could tell the difference :-).

Larry Kilgallen

Re: Trusting GNAT for security software

[Robert Dewar]

Larry said

<<I don't think people theorize this any more about free software than
commercial software, nor any less.  With sufficient funding I could
set up higher bandwidth "mirror" sites for GNAT distribution, and
lacking signatures who would know if I had tampered?  Initially
someone would compare, but eventually they would grow tired.

On the other hand, I could use the same funding to become a "distributor"
of Microsoft software, giving them their full royalties but sending modified
CD-ROMs to the unwitting customers who would not know that I had inserted
bugs in the software.  Microsoft would get a reputation for buggy software.
Who could tell the difference :-).
>>


Actually here, operating in paranoid mode, you are ahead with GNAT, since,
assuming you are using the commercial version of the product, you get it
directly from the vendor, with no intervening distributors. Yes, it is
possible that the public versions could be compromised, although I think
it is more likely that would happen through an accident, than through
design -- but one cannot imagine a paranoid security-concious project
using unsupported freeware of unknown provenance, can one???

<<Well just because GNAT is written to rely on GNAT-specific features,
that doesn't mean your security software should be that way.  In fact,
I would be quite suspicious of a security product delivered in source
form allegedly for reasons of security if the instructions were that
I had to use a particular compiler even though it was written in an
internationally standardized language.
>>

Surely you have not been dazzled into believing that because something
is written in a standardized language, it is automatically portable!
There are many legitimate implementation dependencies in almost all
languages. It is actually very unusual for a large project to be
100% portable from one compiler to another without any changes of
any kind at all -- not impossible, but most certainly unusual.

Probably the most secure way of distributing security type products is
to deliver the binary, together with the corresponding source. That way
the customer can, if they like, repeat the entire certification process,
or at least that part of the procedures that are related to the code itself,
as opposed to the procedures used to generate the code.

The danger of depending on source distribution for a high security product
without any reference binary, is that you do not have a 100% guarantee that
you have correctly compiled the product and got a version that corresponds
to the one that has been certififed. FOr exampled in a nasty case, the compiler
might have a previously undetected bug that causes it to generate bad code
on the 29th of March, due to the date routine making a wild store.

Re: Trusting GNAT for security software

[Andi Kleen]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:

> > Actually I think a university project, particularly one working with
> > openly available sources, would be extremely hard to subvert in the manner
> > that Marcus' paranoid thinking suggests. Many students had full access to
> > every bit of information throughtout the development.
> 
> But those involved in security work are supposed to think paranoid.
> If you don't have a list of possible attacks against which you do not
> have a provable defense, then you haven't thought hard enough.  AMD
> might have a special circuit inside their chips that recognizes code
> generated by GNAT and if it finds it is doing triple-DES squirrels
> away the key in a secret register.

Another funny thing. Most newer Intel chips (PPro+) are rumoured to have
loadable Microcode [SCO apparently once released a OS update that fixed
microcode bugs]. Now you could patch the microcode to detect some known
codes...

-Andi 

Re: Trusting GNAT for security software

[Larry Kilgallen]

In article <m3btvp1zo2.fsf@fred.muc.de>, Andi Kleen <ak@muc.de> writes:

> Another funny thing. Most newer Intel chips (PPro+) are rumoured to have
> loadable Microcode [SCO apparently once released a OS update that fixed
> microcode bugs]. Now you could patch the microcode to detect some known
> codes...

That was a feature of the better VAXes for years.

Now with Alpha, there is PALcode which provides the same capability
in a bit more chip-independent fashion.  It turns out you cannot
intercept arbitary (implemented) instructions, but you can certainly
get all the calls to privileged OS features, which is quite enough to 
be concerned about for security purposes.

So GNAT (or any other compiler) is just one in a long list of possible
security risks, and the primary malice risk is probably the operators
you hire for your own site rather than the compiler writers who likely
do not know (or care) that your project is using their compiler.

Larry Kilgallen

Re: Trusting GNAT for security software

[Larry Kilgallen]

In article <dewar.888807733@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Actually here, operating in paranoid mode, you are ahead with GNAT, since,
> assuming you are using the commercial version of the product, you get it
> directly from the vendor, with no intervening distributors. Yes, it is
> possible that the public versions could be compromised, although I think
> it is more likely that would happen through an accident, than through
> design -- but one cannot imagine a paranoid security-concious project
> using unsupported freeware of unknown provenance, can one???

Certainly from a security perspective, any factor which causes fuller
analysis and more attention to details is to be desired.

> Larry said

> <<Well just because GNAT is written to rely on GNAT-specific features,
> that doesn't mean your security software should be that way.  In fact,
> I would be quite suspicious of a security product delivered in source
> form allegedly for reasons of security if the instructions were that
> I had to use a particular compiler even though it was written in an
> internationally standardized language.
>>>
> 
> Surely you have not been dazzled into believing that because something
> is written in a standardized language, it is automatically portable!
> There are many legitimate implementation dependencies in almost all
> languages. It is actually very unusual for a large project to be
> 100% portable from one compiler to another without any changes of
> any kind at all -- not impossible, but most certainly unusual.

I would not expect to be able to use a different compiler with zero effort,
but for a security product to have been purposefully programmed to prevent
use of other compilers would raise a red flag.  On the other hand, that
might lead to more thorough analysis, which is good.

To me this an entirely different issue than whether GNAT requires GNAT.

<relevant comments about not depending entirely on source snipped>

Larry Kilgallen