Re: Beware: Rep spec on an enumeration type causes code explosion

[gwinn@res.ray.com (Joe Gwinn)]

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