Re: Starting point

[root <evpopkov@carry.neonet.lv>]

> that's what you usually do in a code audit - take an old version and go
> from there, trying to understand the reason behind every change.
>
> the only problem with  that approach is that for a  program as complex as
> the
> Linux kernel, it'll take a looong time.

 I  understand,  or at  least-  pretend  to, all  the  caveats  of the  `by
speciality' approach, compared to `by version' approach.
 However,  the  former  seems  more  preferrable to  me  because  it  gives
better coverage  and concentration. `Speciality' approach  is hidden within
`versioned' audit. Say, we decide to go with 2.4.x, OK. Then we must figure
what to begin with,  will it be core scheduling, or  fs, or networking. Why
can't we  take a particular  subsystem and  examine its evolution  in time,
since older kernels?
 2.0.x is more stable? Contains  less suspicious code fragments? Then we'll
just spend  less time on it  and get faster  to the recent versions.  If we
start with 2.4.x, older versions will fall out of scope forever.


---

 "Teddy - I suppose Mummy and Daddy are real, aren't they?"
 Teddy said, "You ask such silly questions, David. Nobody knows what
'real' really means. Let's go indoors."

 Brian W. Aldiss, Supertoys Last All Summer Long


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/