| |||||||||||||
Kernel vulnerabilities: old or new?Kernel vulnerabilities: old or new?Posted Oct 20, 2010 3:27 UTC (Wed) by martinfick (subscriber, #4455)In reply to: Kernel vulnerabilities: old or new? by bfields Parent article: Kernel vulnerabilities: old or new?
> So one way to phrase your criticism is: the sample chosen (of kernel vulnerabilities found this year) is biased towards older bugs, because it takes time for kernel bugs to be found.
No, my criticism is that the sample is biased towards the known bugs. It is not very useful to attempt to compare the known to the unknown. There could be an infinite amount of bugs being introduced, we have no idea. Each "fix" could even introduce more bugs than it fixes. The discovery rate is unrelated to the introductory rate! Looking at a subset of the possible bugs tells you nothing conclusive about the total except that the total includes the subset. It's like trying to determine when we will have mastered intergalactic space travel from the rate of scientific papers published during the 20th century. :)
(Log in to post comments)
Kernel vulnerabilities: old or new? Posted Oct 20, 2010 8:36 UTC (Wed) by nix (subscriber, #2304) [Link]
Quite so. You'd get the same results if there was one very numerous class of security holes that almost always took at least ten years to track down, and other less numerous classes that were normally found faster. The same results, but the rate of hole introduction would be going *up* since 2.6.12 because the rate of kernel growth shot up since the introduction of git: we just haven't found any of those bugs yet.
(for the record this is a rather unlikely scenario -- 'digital kuru' if you will -- but it is a valid interpretation of the data, I think.)
|
|||||||||||||