Kees cook I make a blog post in which has raised concerns about the bug fixing process ongoing in the stable branches of the Linux kernel and is that mention that week by week about a hundred corrections are included on stable branches, which is too much and requires a lot of effort to maintain Linux kernel-based products.
According to Kees, the kernel error handling process is bypassed and kernel lacks at least 100 additional developers to work in a coordinated manner in this area. In addition to mentioning that major kernel developers regularly fix bugs, but there is no guarantee that these fixes will carry over to third-party kernel variants.
In doing so, he mentions that users of various Linux kernel-based products also have no way of controlling which bugs are fixed and which kernel is used on their devices. Ultimately, vendors are responsible for the security of their products, but faced with a very high rate of patches on stable kernel branches, they were faced with the choice of migrating all patches, selectively migrating the most important ones, or ignoring all patches. patches.
Upstream kernel developers can fix bugs, but they have no control over what a downstream vendor chooses to incorporate into their products. End users can choose their products, but they generally have no control over which bugs are fixed or which kernel is used (a problem in and of itself). Ultimately, vendors are responsible for keeping their product cores safe.
Kees cook suggests that the optimal solution would be to transfer only the most important fixes and vulnerabilities, but the main problem is to separate these errors from the general flow, since most of the emerging problems are a consequence of the use of the C language, which requires a lot of care when working with memory and pointers.
To make matters worse, many potential vulnerability fixes are not tagged with CVE identifiers or do not receive a CVE identifier some time after the patch is released.
In such an environment, it is very difficult for manufacturers to separate minor fixes from major security issues. According to statistics, more than 40% of vulnerabilities are removed before CVE assignment, and on average the delay between a fix release and a CVE assignment is three months (that is, at the beginning, a perceives a solution as a common mistake,
As a result, not having a separate branch with fixes for the vulnerabilities and not receiving information about the connection with the security of this or that problem, manufacturers of Linux kernel-based products have to continually transfer all fixes of the new stable branches. But this work is labor-intensive and faces resistance from companies due to fears of regressive changes that could disrupt the normal operation of the product.
Keys Cook believes that the only solution to keep the kernel secure at a reasonable cost in the long term is to relocate patch engineers to crazy kernel buildsl to work together in a coordinated way to maintain patches and vulnerabilities in the upstream kernel. As it stands, many vendors don't use the latest kernel versions in their products and backport fixes on their own, that is, it turns out that engineers from different companies duplicate each other's work, solving the same problem.
For example, if 10 companies, each with an engineer supporting the same fixes, redirect these engineers to fix bugs upstream, instead of migrating one fix, they could fix 10 different bugs for the overall benefit or come together to review the bugs. proposed changes. And avoid including buggy code in the kernel. The resources could also be used to create new code analysis and testing tools that would automatically detect at an early stage the typical error classes that crop up over and over again.
Keys Cook also proposes to use more actively automated testing and fuzzing directly in the kernel development process, use continuous integration systems and abandon the archaic management of development through e-mail.
Source: https://security.googleblog.com