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: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-05 15:15:28 PST Path: archiver1.google.com!newsfeed.google.com!postnews1.google.com!not-for-mail From: mjsilva@jps.net (Mike Silva) 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: 5 Aug 2001 15:15:28 -0700 Organization: http://groups.google.com/ Message-ID: <5267be60.0108051415.9de7bcd@posting.google.com> References: <9k9if8$rn3$1@elf.eng.bsdi.com> <3B687EDF.9359F3FC@mediaone.net> <5267be60.0108021911.7d8fe4@posting.google.com> NNTP-Posting-Host: 209.239.197.170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 997049728 29135 127.0.0.1 (5 Aug 2001 22:15:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 5 Aug 2001 22:15:28 GMT Xref: archiver1.google.com comp.lang.ada:11327 comp.lang.c:72336 comp.lang.c++:80159 comp.lang.functional:7323 Date: 2001-08-05T22:15:28+00:00 List-Id: "Tor Rustad" wrote in message news:... > "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). I certainly agree that having the primary unit shut down when the secondary unit had already shut down was not smart. > 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). Yep. > 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? I have seen hints that it was simply for telemetry. Maybe somebody has better knowledge. Mike