0

An answer to this question would provide insight and references about how the linux kernel source code is reviewed prior to be released?

Particular interesting aspect of this question to me are:

  • Who and how many persons review the code that is provided, i.e. via a pull request?
  • Is there a change that a backdoor could go undedected, in particular considering firmware blobs?
  • Are static/dynamic code analysis tools used, and if so to guard against accidental bugs only, or also against deliberate backdoors implants?

Info: I have looked at the LKML FAQ which provides the following statement related

  1. How do I get my patch into the kernel?

    (RRR) Depending on your patch there are several ways to get it into the kernel. The first thing is to determine under which maintainer does your code fall into (look in the MAINTAINERS file). If your patch is only a small bugfix and you're sure that it is 'obviously correct', [...]
    [...] here's another important bit: one purpose of the list is to get patches peer-reviewed and well-tested.[...]

The core of the question is some insight, what this 'obviously correct' and peer-reviewed (e.g. who, how many?).

For sake of a concrete example, I looked at the example of the commit log for the staged rtl8188eu wifi chip device driver, found in /usr/srx/linux/drivers/staging/rtl8188eu:

  • number of commits modifying file of [...]/rtl8188eu is 1560 git log --format="%x00%h%n%an%n%cn%n%s" --name-status | tr '\0\n' '\n\0' | grep -a '8188eu' | tee commits | wc -l
  • number of authors 190 persons
    sed 's/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq | wc -l
  • number of commiters 12 (Al Viro, David S. Miller, Greg Kroah-Hartman, Ingo Molnar, Jeff Kirsher, Jiri Kosina, Johannes Berg, John W. Linville, Kees Cook, Linus Torvalds, Michael S. Tsirkin, Peter P Waskiewicz Jr)
    sed 's/^[^\x00]*\x00//g;s/^[^\x00]*\x00//g;s/\x00.*$//g' <commits | sort | uniq
3

Who and how many persons review the code that is provided?

Generally speaking, at least the subsystem maintainer, and typically at least one or two other developers who are interested in the general topic of your patch. For example, a security-improving patch would typically involve security-focused developers as well as the maintainers of the subsystems being modified. More complex patches get more attention, unless their developers fail to get anyone interested in them. Patches which introduce too much maintenance cost don’t get in (see this example by yours truly).

Is there a chance that a backdoor could go undedected, in particular considering firmware blobs?

Firmware blobs are opaque pretty much by definition, so yes, there is a chance that a backdoor could go undetected. More generally, when you see the complexity of some attacks on e.g. web browsers, it’s certainly conceivable that a backdoor could be introduced over the course of a number of seemingly-unrelated patches. That’s especially true if the seemingly-unrelated patches end up being reviewed and approved by different developers.

Are static/dynamic code analysis tools used, and if so to guard against accidental bugs only, or also against deliberate backdoors implants?

Not as part of the review process, as far as I know; but there are a number of groups running analysis tools against the kernel at regular intervals, and reporting and/or fixing the issues raised then. One example is the Coverity scans.

What this obviously correct?

That varies widely. Patches are carefully reviewed (see this comment on a simple patch), but a patch submitter might get less reaction than expected, especially since they often are less familiar with the code they’re changing than the subsystem maintainer — so a change which might feel complex to its author might appear obvious to the maintainer. The kernel development community also tends to avoid the “relaxed reviews of large patches” syndrome by requiring that large patches are split up into reviewable chunks, and also often requiring that large patch sets get more reviews. Careful reviews don’t guarantee correctness unfortunately; one of my patches was fixed up by the subsystem maintainer, with the result that it got merged with a nasty bug! (There’s a recent analysis somewhere of how maintainers deal with their own patches, which is relevant.)

Patches also get reviewed in aggregate when subsystem maintainers merge trees, all the way up to the main maintainer (Linus, Greg, and the various stable maintainers). That doesn’t often result in changes being requested, but it does happen sometimes.

It’s important to consider the social aspect of all this too. It’s much easier for a well-known developer to get reviews; my general experience in the software development world would also suggest that well-known developers might see their patches less scrutinised... For less well-known developers, having a well-known reviewer approve your patch can make it easier to get in too. In general, it helps to know the right people, or piggy-back on the right efforts (e.g. participate in a hardening campaign).

  • I really appreaciate your answer with provides some of the insights I was looking for. Being a somewhat tinfoil person, it is yet reassuring to have confirmation about multiple persons reviewing the code. Still the possibilities to hide stuff in C a la underhanded C contest makes me wish stuff like the device drivers with source code often comming from large coorporations/manufactorers makes me wish that stuff would not end up being run in Ring 0 - as monolithic kernels do, but more being implemented similar to FUSE. thank you – humanityANDpeace Oct 5 '18 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.