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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-03 18:00:15 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!news3.oke.nextra.no.POSTED!not-for-mail From: "Tor Rustad" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.functional References: <9k9if8$rn3$1@elf.eng.bsdi.com> <3B687EDF.9359F3FC@mediaone.net> <5267be60.0108021911.7d8fe4@posting.google.com> Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: NNTP-Posting-Host: 130.67.133.173 X-Complaints-To: news-abuse@nextra.no NNTP-Posting-Date: Sat, 04 Aug 2001 02:59:52 MEST Organization: Nextra Public Access X-Trace: news3.oke.nextra.no 996886792 130.67.133.173 Date: Sat, 4 Aug 2001 02:26:41 +0200 Xref: archiver1.google.com comp.lang.ada:11270 comp.lang.c:72041 comp.lang.c++:79853 comp.lang.functional:7284 Date: 2001-08-04T02:26:41+02:00 List-Id: "Mike Silva" wrote in message > "Tor Rustad" wrote in message > > > > IIRC, the problem was related to excetion handling of a hardware > > fault...not > > exactly a Ada programming bug, but more a technical design bug...? > > Very briefly, they had proven to their satisfaction that the offending > variable could never go out of range (of a 16 bit integer) on the > Ariane 4, and any unhandled exception, such as the one that occurred > when it *did* go out of range on the -5, was presumed to be due to a > hardware fault, leading to shutdown of the unit. Since both units > received the same "impossible" value, due to the -5s different > trajectory, both shut down... Since both HW units got the same "impossible" value, it looks to me as the probability for a HW fault should have been insignificant. The point in verifying calculations in independent HW, is to detect and recover from HW faults. So since the result from *both* HW units was the same, my conclusion would be that it was a programming/design bug and not a HW fault. However, error recovery from this type of errors (in general) is very difficult (if not impossible). Hmm...in fact for that reason, I have always assumed that in extremely critical systems, you simply use independent design teams (and programmers) to develop the second unit, and *not* just duplicate the first unit (which must have the same identical bugs or flaws). IMHO, using 16-bit integers, is also a design issue. If there was strict performance requirements to be met, well then why not use a faster programming language, where the programmers perhaps could afford to use 32-bit integers? Even in non-critical systems, I do think that many programmers try to take future demands into consideration and make sure their SW works not only according to current specs. Since they know that somebody else may later change other parts of the system, possibly without re-testing all the SW again. > Not only wasn't it a programming bug, I wouldn't even call it a design > bug, since hardware failure would have been the correct presumption > based on the Ariane 4 trajectory data. It was an untested, > unjustified re-use bug. To re-use an old design or not, is also design descision IMHO. Not testing it, is a really bad descision, perhaps the biggest one in this sad story. -- Tor