Re: [Lit.] Buffer overruns
From: Brian Inglis (Brian.Inglis_at_SystematicSW.Invalid)
Date: 02/01/05
- Next message: infobahn: "Re: [Lit.] Buffer overruns"
- Previous message: Décio Luiz Gazzoni Filho: "Re: EC-PRNG"
- In reply to: Trevor L. Jackson, III: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 01 Feb 2005 16:51:01 GMT
On Tue, 01 Feb 2005 07:28:23 -0500 in alt.folklore.computers, "Trevor
L. Jackson, III" <tlj3@comcast.net> wrote:
>David Wagner wrote:
>
>> infobahn wrote:
>>
>>>David Wagner wrote:
>>>
>>>>Quite possibly a team of N people is enough to catch most bugs, if you
>>>>take N large enough. But can we afford to take N large enough, and have
>>>>all N people review all the code in our system? Often not; it often
>>>>costs too much. So that is not a general answer. I haven't heard you
>>>>tell us what we should be doing when we can't afford such an approach.
>>>
>>>Three words. Modularise, modularise, and modularise. (That's four
>>>words.)
>>
>>
>> Yes. Decomposing your software for security is a good thing. So is
>> architecting the system so that you reduce the size of the TCB, reduce
>> the privilege needed for most subsystems, and so on. Great stuff that
>> gives you huge leverage, without a doubt.
>>
>> But, there is a catch. This 'decomposition for security' is not easy
>> stuff. A few people are very skilled at it, but there are only so many
>> Dan Bernsteins (to pick a random example) in the world. For the rest
>> of the programmers (the mere mortals, people like me), the question is,
>> can we figure out how to teach them this skill? That seems to be very
>> difficult. A good demonstration of this point: Try to come up with books
>> that do a good job of teaching this skill. Every one I can think of has
>> severe limitations. And part of the reason, I suspect, is that this is
>> a craft that a lucky few are good at, but that seems very hard to teach.
ISTM that good design judgement, as in other fields, may be more of a
talent than a skill.
>All that you said it true, but there is another side to that coin. In
>the larger domain of math/science, Newton was perhaps the brightest that
>ever lived. Are we now, post-Newton, stuck with the realization that we
>are inadequate to the task of using the fruits of his inspirations
>because we are not his equal or superior? In fact we are not stuck.
>One of the wonders of the scientific method is that reasonably ordinary
>people can contribute.
>
>In the CS domain we don't all have to be Djikstra or Knuth to utilize
>the fruits of their discoveries either. In fact we can use many of the
>techniques they pioneered in order to increase our own productivity.
>Learning to decompose large, and thus insoluble, problems into
>manageable chunks is not a skill restricted to CS. It is a fundamental
>engineering skill, perhaps _the_ fundamental engineering skill. It is
>teachable. And it does not require ridiculous levels of cognitive
>horsepower to be effective.
The selection of appropriate chunks requires good judgement: somewhere
between monolithic and hundreds of trivial functions.
>The problem we face is not the lack of supremely skilled talent. It is
>the lack of interest in acquiring the skills necessary to do the work
>with acceptable quality. It is not that fact that there is nobody who
>can do the work adequately. It is much worse than that. The problem is
>that there is are very few who care about doing the work adequately.
^to pay to do^
>The methodology, discipline, and attitude/culture of craftsmanship
>yielding quality software has been available for a couple decades at
>least. But it is largely ignored, though occasionally given lip
>service, in the vast majority of development organizations.
>
>For reference checkout the SEI statistics on the distribution of
>development organizations. The only explanation for the prevalence of
>the most primitive organizations is that none of them care to do any better.
^to pay
> > And the real problem is that we need something more than a craft.
> > We need something that mere mortals can learn, something that
> > Microsoft programmers can learn. Saying "hire Dan Bernstein"
> > or "hire Doug Gwyn" or "hire infobahn" doesn't scale.
Maybe it's not a learnable skill, maybe it's a talent?
>We have something mere mortals can learn. But you can't make them do so
>and there are insufficient incentives to motivate them to do so on their
>own.
Firing the shoddy and unproductive would be a good start.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
- Next message: infobahn: "Re: [Lit.] Buffer overruns"
- Previous message: Décio Luiz Gazzoni Filho: "Re: EC-PRNG"
- In reply to: Trevor L. Jackson, III: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
