Re: [Lit.] Buffer overruns

From: Trevor L. Jackson, III (tlj3_at_comcast.net)
Date: 03/16/05


Date: Wed, 16 Mar 2005 09:22:13 -0500

jmfbahciv@aol.com wrote:

> In article <m3sm2xhujr.fsf@lhwlinux.garlic.com>,
> Anne & Lynn Wheeler <lynn@garlic.com> wrote:
>
>>jmfbahciv@aol.com writes:
>>
>>>Sure. Another note would be that there are only a few auto
>>>manufacturers and the quality of their distribution can be
>>>controlled (to the point of too much control) by governments. OTOH,
>>>there are millions of people producing code and gazillions of
>>>computers producing and distributing code...and data. I predict
>>>that, if we don't start to solve these problems in-house,
>>
>>there is also a large difference in the number of c compiler writers
>>and the number of c coders. one of the early thread postings was that
>>most c-environment string copy operations are to buffer areas that
>>have no infrastructure defined length. this led to some observations
>
>
> Yes, the results are logrithmic, not linear... (I think I just
> messed up using English ASCII but you'll know what I'm talking
> about...you've been posting about this aspect for years.)
>
>>1) some other environments (like PLI) where both source and target
>>areas had explicit infrastructure defined lengths ... have had
>>significantly lower buffer overflow issues (analogous to reduction in
>>traffic fatalities when various safety related features were
>>introduced).
>
>
> What I would you to speculate about is: If PLI had been
> distributed as freely and widely as C would the oodles of
> code still be "buffer safe"? I've only met PLI once and
> that was in the form of the cards I punched for the guy
> who wrote the code 37 years ago so I don't remember much.
> PLI never got popular because it was a PITA to use. In my
> area one had to drive from Kalamazoo to Ann Arbor, submit
> the card deck, and then drive back with the results because
> a user was only allowed one run/visit.

When was this? Were you visiting a place called North Campus?

>
>
>
>>2) automatic bounds checking is dependent on infrastructure
>>determinable bounds (like start/end or start/length) ... it would
>>appear to be difficult to implement automatic bounds checking for
>>storage areas that have no infrastructure determinable bounds.
>>
>>the corollary was that if storage areas had infrastructure
>>determinable bounds ... say in order that automatic bounds checking
>>implementation were possible (aka #2), then C environmental libraries
>>might be able to also take advantage of such infrastructure
>>determinable bounds ... which might result in C implemented
>>applications having frequency of buffer overlow events much more akin
>>to other application environments that had infrastructure determinable
>>bounds as part of their basic environment (aka #1).
>>
>>misc ...
>>http://www.garlic.com/~lynn/subpubkey.html#overflow
>
>
> But would the evolution of the functionality of PLI
> match C? Would the bounds checking have given the
> coders enough of a headache during their development
> cycles that they would have defaulted to an "easier"
> technique?
>
> My apologies if I'm not writing clearly enough.
>
> PLI was guarded by formidable bit gods. C was not. C was
> not guarded because ATT's business was not primarily the
> computer biz. The messes we see in Unix are directly
> because of that...IMO.

It would not have gotten the widespread availability of C because AFAICT
it is much harder to port to an arbitrary (and tiny) machine architecture.

/tj3



Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... areas had explicit infrastructure defined lengths ... ... storage areas that have no infrastructure determinable bounds. ... to other application environments that had infrastructure determinable ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... > areas had explicit infrastructure defined lengths ... ... > 2) automatic bounds checking is dependent on infrastructure ... > storage areas that have no infrastructure determinable bounds. ...
    (sci.crypt)