* Compiling gnat into gcc-2.8.0 @ 1998-02-25 0:00 Kevin Taylor 1998-02-26 0:00 ` Stephen Leake 1998-02-26 0:00 ` Compiling gnat into gcc-2.8.0 Simon Wright 0 siblings, 2 replies; 18+ messages in thread From: Kevin Taylor @ 1998-02-25 0:00 UTC (permalink / raw) 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 .. .. .. .. ........................ .............................. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-25 0:00 Compiling gnat into gcc-2.8.0 Kevin Taylor @ 1998-02-26 0:00 ` Stephen Leake 1998-02-26 0:00 ` Robert Dewar 1998-02-27 0:00 ` Markus Kuhn 1998-02-26 0:00 ` Compiling gnat into gcc-2.8.0 Simon Wright 1 sibling, 2 replies; 18+ messages in thread From: Stephen Leake @ 1998-02-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-26 0:00 ` Stephen Leake @ 1998-02-26 0:00 ` Robert Dewar 1998-02-27 0:00 ` Markus Kuhn 1 sibling, 0 replies; 18+ messages in thread From: Robert Dewar @ 1998-02-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-26 0:00 ` Stephen Leake 1998-02-26 0:00 ` Robert Dewar @ 1998-02-27 0:00 ` Markus Kuhn 1998-02-27 0:00 ` Robert Dewar 1998-02-27 0:00 ` Richard Kenner 1 sibling, 2 replies; 18+ messages in thread From: Markus Kuhn @ 1998-02-27 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-27 0:00 ` Markus Kuhn @ 1998-02-27 0:00 ` Robert Dewar 1998-02-27 0:00 ` Andi Kleen 1998-02-27 0:00 ` Richard Kenner 1 sibling, 1 reply; 18+ messages in thread From: Robert Dewar @ 1998-02-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-27 0:00 ` Robert Dewar @ 1998-02-27 0:00 ` Andi Kleen 1998-02-27 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 18+ messages in thread From: Andi Kleen @ 1998-02-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-27 0:00 ` Andi Kleen @ 1998-02-27 0:00 ` Larry Kilgallen 1998-02-27 0:00 ` Robert Dewar 0 siblings, 1 reply; 18+ messages in thread From: Larry Kilgallen @ 1998-02-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-27 0:00 ` Larry Kilgallen @ 1998-02-27 0:00 ` Robert Dewar 0 siblings, 0 replies; 18+ messages in thread From: Robert Dewar @ 1998-02-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-27 0:00 ` Markus Kuhn 1998-02-27 0:00 ` Robert Dewar @ 1998-02-27 0:00 ` Richard Kenner 1998-03-01 0:00 ` Trusting GNAT for security software Markus Kuhn 1 sibling, 1 reply; 18+ messages in thread From: Richard Kenner @ 1998-02-27 0:00 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-02-27 0:00 ` Richard Kenner @ 1998-03-01 0:00 ` Markus Kuhn 1998-03-01 0:00 ` Robert Dewar 0 siblings, 1 reply; 18+ messages in thread From: Markus Kuhn @ 1998-03-01 0:00 UTC (permalink / raw) 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/> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-01 0:00 ` Trusting GNAT for security software Markus Kuhn @ 1998-03-01 0:00 ` Robert Dewar 1998-03-01 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 18+ messages in thread From: Robert Dewar @ 1998-03-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-01 0:00 ` Robert Dewar @ 1998-03-01 0:00 ` Larry Kilgallen 1998-03-01 0:00 ` Robert Dewar 1998-03-02 0:00 ` Andi Kleen 0 siblings, 2 replies; 18+ messages in thread From: Larry Kilgallen @ 1998-03-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-01 0:00 ` Larry Kilgallen @ 1998-03-01 0:00 ` Robert Dewar 1998-03-02 0:00 ` Larry Kilgallen 1998-03-02 0:00 ` Andi Kleen 1 sibling, 1 reply; 18+ messages in thread From: Robert Dewar @ 1998-03-01 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-01 0:00 ` Robert Dewar @ 1998-03-02 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 18+ messages in thread From: Larry Kilgallen @ 1998-03-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-01 0:00 ` Larry Kilgallen 1998-03-01 0:00 ` Robert Dewar @ 1998-03-02 0:00 ` Andi Kleen 1998-03-02 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 18+ messages in thread From: Andi Kleen @ 1998-03-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Trusting GNAT for security software 1998-03-02 0:00 ` Andi Kleen @ 1998-03-02 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 18+ messages in thread From: Larry Kilgallen @ 1998-03-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-25 0:00 Compiling gnat into gcc-2.8.0 Kevin Taylor 1998-02-26 0:00 ` Stephen Leake @ 1998-02-26 0:00 ` Simon Wright 1998-02-26 0:00 ` Robert Dewar 1 sibling, 1 reply; 18+ messages in thread From: Simon Wright @ 1998-02-26 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Compiling gnat into gcc-2.8.0 1998-02-26 0:00 ` Compiling gnat into gcc-2.8.0 Simon Wright @ 1998-02-26 0:00 ` Robert Dewar 0 siblings, 0 replies; 18+ messages in thread From: Robert Dewar @ 1998-02-26 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~1998-03-02 0:00 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-02-25 0:00 Compiling gnat into gcc-2.8.0 Kevin Taylor 1998-02-26 0:00 ` Stephen Leake 1998-02-26 0:00 ` Robert Dewar 1998-02-27 0:00 ` Markus Kuhn 1998-02-27 0:00 ` Robert Dewar 1998-02-27 0:00 ` Andi Kleen 1998-02-27 0:00 ` Larry Kilgallen 1998-02-27 0:00 ` Robert Dewar 1998-02-27 0:00 ` Richard Kenner 1998-03-01 0:00 ` Trusting GNAT for security software Markus Kuhn 1998-03-01 0:00 ` Robert Dewar 1998-03-01 0:00 ` Larry Kilgallen 1998-03-01 0:00 ` Robert Dewar 1998-03-02 0:00 ` Larry Kilgallen 1998-03-02 0:00 ` Andi Kleen 1998-03-02 0:00 ` Larry Kilgallen 1998-02-26 0:00 ` Compiling gnat into gcc-2.8.0 Simon Wright 1998-02-26 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox