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: 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-07 16:22:20 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!wn4feed!worldnet.att.net!135.173.83.71!wnfilter1!worldnet-localpost!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3B7078C3.60194D58@worldnet.att.net> From: James Rogers X-Mailer: Mozilla 4.76 [en] (Win98; 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> <3B6F5BB2.A879B933@worldnet.att.net> <%DLb7.26505$B37.537792@news1.rdc1.bc.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 07 Aug 2001 23:22:19 GMT NNTP-Posting-Host: 12.74.161.245 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 997226539 12.74.161.245 (Tue, 07 Aug 2001 23:22:19 GMT) NNTP-Posting-Date: Tue, 07 Aug 2001 23:22:19 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:11551 comp.lang.c:72778 comp.lang.c++:80807 Date: 2001-08-07T23:22:19+00:00 List-Id: Kaz Kylheku wrote: > > >Oh yes, when calling the Put and Get entries, your code must execute > >in the calling thread. That thread must suspend until the entry > >executes. > > > >The entry may only execute when the boundary condition is true, and > >no other entry is concurrently accessing the protected object. > > All done by the mutex and condition waits. Not quite. A mutex and condition waits do not provide a queue for the waiting tasks. This queue must provide orderly access to the protected object when the condition allows. If you have functions associated with the protected object (i.e. read only functions) then you must allow multiple threads to access the object through those functions simultaneously, without mutex locking. At the same time, the entries (functions that update the object) must be blocked by the mutex so that they are prevented from simultaneous access, even when the read only functions are accessing the object. The read only functions must be blocked from accessing the object when an update function is accessing the object. What will you do when your platform does not support POSIX threads? You will have to recode the non-conforming parts (in a POSIX sense) to use the local platform's approach. This appears to add a significant effort in design, coding, testing, and system documentation. It also adds complexity in configuration management. > >You will have to implement the protected object as a template to be > >equivalent. This means that you must find some way to specify that > >one of the generic parameters is an integer greater than or equal to > >1. If the parameter does not meet this requirement the code must not > >compile. Putting the check in runtime code is not equivalent. > > In the C++ code, this translates to a need to verify that the BufferSize > template parameter is greater than zero. The constraint on array > declarations will take care of this for me: If the parameter is zero > or negative, the array will be declared as having zero or negative > elements. (The parameter can't be negative because it's an unsigned type, > size_t). So this means that you must wait until run time to perform the checking. It also means that you allow the system to create a useless, zero size communication object. Neither of these options thrill me. Calls to a zero size object should always fail because the object is simultaneously both full and empty all the time. Checking the parameter at run time means that I must be satisfied with having to wait until run time to find out if the parameter is correct. This check may need to be made many times in the system, assuming the system creates many instances of the template object. Therefore, fixing the problem may take several iterations, where a simple compiler check will find all the problems at once. > (In general, you can write a compile_time_assert() macro which exploits > array constraint checks in order to verify some predicate over a constant > expression. I learned this trick from Chris Torek of BSDi, Inc). Interesting. Does this mean that there is only one such macro in your system, providing only one size of circular buffer? If so, it seems to limit the usefulness of defining the buffer in a template. > > >To make the code truly equivalent you must not define your data to > >be dynamically allocated. All items placed on the buffer must be > >statically allocated. > > Done: it's a simple low-level array that's integrated into the objects. No > std::vector or similar braindamage. I think you misunderstood my point here. The data placed on the C++ version of a protected object must not be dynamically allocated. I assumed the buffer itself would be implemented in a primitive C style array for efficiency purposes.