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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ca9eef4d5e2078ea X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Beware: Rep spec on an enumeration type causes code explosion Date: 1997/12/17 Message-ID: #1/1 X-Deja-AN: 299122322 Content-Transfer-Encoding: 7bit References: <348F3DFC.10DB@nospam.flash.net> <3490252D.6B550F17@ac3i.dseg.ti.com> <3496D55F.1312429E@ac3i.dseg.ti.com> Content-Type: text/plain; charset=us-ascii Organization: Raytheon Electronic Systems Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1997-12-17T00:00:00+00:00 List-Id: In article <3496D55F.1312429E@ac3i.dseg.ti.com>, johnv@ac3i.dseg.ti.com wrote: > Joe Gwinn wrote: > > > > I have to disagree somewhat. We were using enumeration types as message > > type IDs all over the place, not just at the edges. For safety-critical > > messages, the enumerations are not permitted to be numerically contiguous, > > being required to differ in at least four bits from all other message type > > integer codes. This 4-bit requirement is intended to greatly reduce the > > probability of message spoofing. (I know this isn't by itself > > sufficient. This isn't the entire defense, only the part relevant to the > > current issue.) > > I don't see how this requirement conflicts with the idiom I sketched > before (derive a "holey" enumeration type from a parent "contiguous" > enumeration type, and rely on Ada type conversions to provide the > necessary mapping). Your program only needs to deal with these "secure" > but "holey" message id bit patterns at its edges, where it receives and > unpacks input messages (whose provenance may be questionable) and where > it must pack up and transmit output messages (and establish their > provenance). But once you've checked your input messages against > whatever security measures you've established (including among other > things 'Valid-ating their "holey" message id's) there is hardly any > reason for your program to continue using the "holey" representation > internally. Particularly if you proceed to use message id's in a lot of > for-loops and array-indexes and other such enumerated-type operations > that threaten to "blow up" if the type is "holey". If you simply > type-convert the "holey" external versions of your message id's into > "contiguous" internal versions, right at the point of input, then you > incur the cost of the expensive mapping just once, rather than > repeatedly throughout your program. The nice thing about this is that > you don't have to give up on using your nice enumeration literals -- you > only have to give up the *representation*. Well, it depends on where one chooses to put the boundaries between safe and unsafe. Because we choose not to attempt safety validation of VxWorks and the various COTS communications systems, an impossible task, every VxWorks task stands alone, so safety critical messages between tasks must have message type IDs differing in at least 4 bits. I think this meets the definition of holey; in fact, it's more hole than anything else, by design. So, can one convert to a compact enumeration within those tasks, defining the "edges" to be the task boundaries? Not really, both by common sense and by a specific contractual safety requirement. Enumeration types within the task are still implemented using physical memory, there being no other way, and thus have no more divine protection from bitflips and other forms of spoofing then they do outside the tasks. There is no physical task boundary; tasks are just an illusion created by VxWorks for the benefit of programmers. So, the four-bit rule must be universal. Note that in VxWorks (as in most embedded realtime operating systems), there is no memory protection barrier separating tasks from one another, and there never has been, even in the most safety-critical of systems. Safety is a product of overall system architecture and design, and cannot be permitted to depend on any one feature or component. Because of the need to talk to entities written in languages other than Ada95, or in Ada95 but compiled and linked at a different time perhaps using a different compiler and compiler version, the specific enumeration mapping must be explicitly nailed down, with no discretion left to any of the various compilers. This was the reason for the rep specs. Now that the rep specs are gone, some other equivalent method will be needed. The holes are absolutely required and thus will remain. Something else will be forced to give. Joe Gwinn