From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 107f24,582dff0b3f065a52 X-Google-Attributes: gid107f24,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-02 13:45:59 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Date: Thu, 2 Aug 2001 16:37:05 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9kcdli$24o$1@nh.pace.co.uk> References: <9kc355$ri0$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 996784626 2200 136.170.200.133 (2 Aug 2001 20:37:06 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 2 Aug 2001 20:37:06 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:11138 comp.lang.c:71747 comp.lang.c++:79474 comp.lang.functional:7226 Date: 2001-08-02T20:37:06+00:00 List-Id: Having been all over that report a number of times and getting grilled by Lockheed Martin on it personally, I've had more than a little experience with it. In the first place, if you check the report, I think you'll find that it states elsewhere that the runtime checks were explicitly removed because there was a speed constraint that had to be met. The checks were removed after static analysis indicated that within the Arianne 4 profile, the numbers would never exceed what was allowed for. In the second place the "Operand Error" they refer to is *not* a standard Ada exception and I and others familiar with the report don't know where the writers extracted this from. However, given the reference to a 64 bit Float converting to a 16 bit integer and having some familiarity with the Mil-Std-1750a microprocessor that was the target machine, we concluded that they were referring to a hardware interrupt that occurs when you perform that particular conversion instruction. (The report writers were not software people and were not necessarily conversant in the precise nomenclature.) This is consistent with the rest of the report's discussion of what the hardware actually did for FDA. I think if you re-read the report and possibly some of the additional commentary you can find on it on the Internet, you may discover that what I'm saying here is accurate. As for the "Software should be considered correct..." part? I am in 100% agreement with you that this is a stupid idea. As for that idea coming from an Ada culture? I doubt it. I don't know of any Ada engineers who believe their software is correct because it is written in Ada or make foolish assumptions that somehow the compiler is going to remove all errors everywhere. Those of us who have spent years in the realtime, embedded, Ada world know better than to make that sort of assumption. The Arianne 5 disaster had everything to do with management assuming they could take an "off the shelf" part designed for one rocket and bolt it onto another rocket and assuming that it would work correctly without ever having tested it. That is a stupid assumption for anyone to make - but it gets done all the time in software and in other disciplines such as mechanical engineering. Its a management problem - not a language problem. The disaster didn't have anything to do with the language used to program the device because the device behaved exactly as it had been designed to do. It was just outside of its designed environment - the same way that using a perfectly good tire from a Corvette as one of the tires for a Boeing 747 would be a major disaster. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Goran Larsson" wrote in message news:GHGGJH.JpI@approve.se... > The following text clearly tells us that the runtime checks (generating > the exception) were in place at least for this conversion. > > | The internal SRI software exception was caused during execution of > | a data conversion from 64-bit floating point to 16-bit signed integer value. > | The floating point number which was converted had a value greater than > | what could be represented by a 16-bit signed integer. This resulted in > | an Operand Error. The data conversion instructions (in Ada code) were not > | protected from causing an Operand Error, although other conversions of > | comparable variables in the same place in the code were protected. > > What made the Ariane design team take the view that "software should be > considered correct until it is shown to be at fault"? Fooled by to much > trust in Ada? >