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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC 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: Ken Garlington <kennieg@nospam.flash.net>
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/17
Message-ID: <3498991B.4498@nospam.flash.net>#1/1
X-Deja-AN: 299221903
Content-Transfer-Encoding: 7bit
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
 <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com> <348F3DFC.10DB@nospam.flash.net>
 <3490252D.6B550F17@ac3i.dseg.ti.com>
 <gwinn-1212971935370001@dh5055236.res.ray.com>
 <3496D55F.1312429E@ac3i.dseg.ti.com>
Mime-Version: 1.0
Reply-To: Ken.Garlington@nospam.computer.org
Content-Type: text/plain; charset=us-ascii
Organization: Flashnet Communications, http://www.flash.net
Newsgroups: comp.lang.ada
Date: 1997-12-17T00:00:00+00:00
List-Id: <comp.lang.ada>


John G. Volan 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). 

In Wichmann's paper, the use of "holey" booleans was to catch local
memory
faults, so this technique is not necessarily limited to "edges".

Of course, is it worth protecting this use of local memory, but not all
the
others? I'm skeptical...