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: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2001-08-07 22:16:03 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc2.on.home.com.POSTED!not-for-mail Message-ID: <3B70CB17.3153DE32@home.com> From: "Warren W. Gay VE3WWG" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> <9keejl$fhj@augusta.math.psu.edu> <3c30da40.0108060848.796d9bd9@posting.google.com> <3B6F3216.F410BBFF@home.com> <3B6F3FAE.B9B9FFCF@globetrotter.qc.ca> <3B6F5BF6.1E22543B@home.com> <3B706538.5AB33833@globetrotter.qc.ca> <3B70BDA5.575D8E6A@home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 05:16:02 GMT NNTP-Posting-Host: 24.141.193.224 X-Complaints-To: abuse@home.net X-Trace: news1.rdc2.on.home.com 997247762 24.141.193.224 (Tue, 07 Aug 2001 22:16:02 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 22:16:02 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:11579 comp.lang.c:72833 comp.lang.c++:80851 Date: 2001-08-08T05:16:02+00:00 List-Id: Kaz Kylheku wrote: > In article <3B70BDA5.575D8E6A@home.com>, Warren W. Gay VE3WWG wrote: > >Chris Wolfe wrote: > >> You stated: "C/C++ _cannot_ provide [runtime checks like boundary > >> checks]" > >> This is false. The compiler I am using is a proprietary one, but.. > > > >He he, but the one you are _using_ - does it provide array bounds > >checking? Does it throw an exception when your integer or unsigned > >type overflows? I expect not. > > Note that unsigned types cannot overflow in C++, by definition. Fair enough. Modular types in Ada don't "overflow" either - they wrap around as in C. However, modular types in Ada wrap around according to the declared modularity. Unsigned types in C only have one implementation defined modularity, according to their size. > >> with a search on Google for C AND "array bounds checking" I found > >> a list of public ones (including a patch for GCC). > > > >That's just peachy. But a sampling of the population of C++ > >users using these, ahem, extensions, are likely to be a small portion > >of all C++ users. > > The bounds checking GCC patches work well, but only support the C front > end (last time I checked). The checking is also not perfect. It's done on > object granularity, not sub-object granularity. Say an array is embedded > in a struct and is not the first member, An overrun of that array can > clobber other members; bounds checking GCC will not detect that. It knows > that an object of a certain size is being manipulated, namely the entire > struct. I can see this as useful for detecting gross errors, but all too many array bounds errors are more subtle that that. They usually are one-offs, or in some cases a few-offs... but overwriting the full extent of the class/structure occurs left often, perhaps. > Anything that is dynamically allocated via a single malloc() call > is also just a single object: essentially a character array that wide. > I think that this is about the best you can do without doing a lot > more work. And it's certainly better than no checking at all! Agreed. > Even protecting primary objects traps nasty classes of errors whereby > a problem in one module causes strange failures in another. Sometimes. At work, I've spent too much time trying to find more subtle problems like somebody's ancient code has corrupted the heap that causes the free() call to fail. Malloc's linked list has probably been stepped on early in the program, but only when all of the structure elements are being freed does this problem rear it's ugly head. But agreed, any help is welcome. > Bounds checking GCC works with the help of a run-time library, which > keeps track of all live objects in a splay tree data structure. > A pointer can be used as a key to locate a node within the tree, > which provides the attributes of the object that the pointer points > to. So the pointer representation is not changed in any way, preserving > binary compatibility with existing code (except that two pointer bit > patterns are reserved for representing special values). While this is useful for debugging purposes, it is by no means a good production mode to use. The _cost_ of looking up each pointer would be enormous by comparison to the compiled in code that Ada provides (no lookups necessary). And of course, the Ada checks can be compiled out at some point too, if that be "the wish of the master". > To my recollection, the run-time library is not thread safe. Also, > programs that use longjmp() causes problems, because it won't be > noted that certain automatic objects no longer exist. (The tracking > of automatic objects is keyed to the same mechanism that is used > for C++ constructors and destructors in the GCC back end, and > longjmp() doesn't play nicely with that). Thank you for the clarification on the GCC front. This certainly gives us all the clear picture of where the compiler stands in comparison to Ada on these "safety" points. > On the plus side, Bounds Checking GCC does nice things with pointer > arithmetic. A bad pointer doesn't have to be dereferenced to be diagnosed, > merely calculated, so that for instance p = malloc(10) + 11 can be > flagged as an error. -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg