How secure is the Linux kernel?
Summary
After several kernel holes, the Linux kernel mailing list discussed in January 2005 how secure the kernel is. Brad Spengler blamed the new development model, while Alan Cox and Theodore Ts’o saw a positive trend. More bugs found did not mean more bugs, but better searching, for example with tools such as Coverity and sparse.
Ideas
- Static analysis tools also find old bugs that had gone unnoticed.
- One bug found triggers the search for similar bugs.
- Most holes required a local user account.
- Bug counts rising in the short term can mean falling bug rates in the long term.
Insights
- The number of reported holes measures search intensity rather than code quality.
- Tool-assisted code review has a lasting effect on the security record of large projects.
Facts
- The analysis tools named were Coverity and sparse.
- Brad Spengler is the developer of the grsecurity security patch.
References
Critique
- The debate remains without figures that would support either position.
Recommendations
- Make static analysis such as Coverity, sparse or clang-tidy a fixed part of the development process.
- Do not judge software by the number of reported holes, but by response time and how they are handled.
Links to the original source and the Web Archive open in a new tab.