What's New in Kernel Development
Bug reports are good. Anyone with a reproducible crash should submit a bug report on the linux-kernel mailing list. The developers will appreciate it, and you'll be helping make Linux better!
A variety of automated bug-hunters are roaming around reporting bugs. One of them is Syzbot, an open-source tool specifically designed to find bugs in Linux and report them. Dmitry Vyukov recently sent in a hand-crafted email asking for help from the community to make Syzbot even more effective.
The main problems were how to track bugs after Syzbot had reported them and how to tell when a patch went into the kernel to address a given bug.
It turned out that Andrey Ryabinin and Linus Torvalds got together to collaborate on an easy solution for Dmitry's problem: Syzbot should include a unique identifier in its own email address. The idea is that anything after a "+" in an email address is completely ignored. So zbrown@gmail.com is exactly the same as zbrown+stoptrump@gmail.com. Andrey and Linus suggested that Syzbot use this technique to include a hash value associated with each bug report. Then, Linux developers would include that email address in the "Reported-By" portion of their patch submissions as part of the normal developer process.
Presto! The unique hash would follow the patch around through every iteration.
Other folks had additional feedback about Syzbot. Eric Biggers wanted to see a public-facing user interface, so developers could check the status of bugs, diagnose which versions of kernels were affected and so on. It turned out that Dmitry was hard at work on just such a thing, although he'd need more time before it was ready for public consumption.
And, Eric W. Biederman was utterly disgruntled about several Syzbot deficiencies. For one thing, he felt Syzbot didn't do a good enough job explaining how to reproduce a given bug. It just reported the problem and went on its merry way. Also, Eric didn't like the use of the Go language in Syzbot, which he said handled threading in a complex manner that made it difficult to interact in simple ways with the kernel.
But Dmitry assured Eric that the significant parts of Syzbot were written in C++ and that the portions using the Go language were not used for kernel interactions. Dmitry also pointed out that Syzbot did provide information on how to reproduce crashes whenever possible, but that it just wasn't always possible, and in a lot of cases, the bugs were so simple, it wasn't even necessary to reproduce them.
In fact, there really wasn't much discussion. Dmitry's original problem was solved very quickly, and it appears that Syzbot and its back-end software is under very active development.
When is security not security? When it guards against the wrong people or against things that never happen. A useless security measure is just another batch of code that might contain an exploitable bug. So the Linux developers always want to make sure a security patch is genuinely useful before pulling it in.
A patch from Dan Aloni recently came in to create the option to encrypt printk() output. This would make all dmesg information completely inaccessible to users, including hostile attackers. His idea was that the less information available to hostile users, the better.
The problem with this, as Steven Rostedt pointed out, was that it was essentially just a way for device makers and Linux distributions to shut out users from meaningfully understanding what their systems were doing. On the other hand, Steven said, he wouldn't be opposed to including an option like that if a device maker or Linux distribution actually would find it legitimately useful.
He asked if anyone on the mailing list was part of a group that wanted such a feature, but no one stepped forward to defend it. On the contrary, Daniel Micay, an Android security contributor who was not part of the official Android development team, said that Android already prevented users from seeing dmesg output, using the SELinux module. So, Dan's patch would be redundant in that case.
The mailing list discussion petered out around there. Maybe the goal of the patch after all was not about protecting users from hostile attackers, but about protecting vendors from users who want control of their systems.
The reason I sometimes write about these patch submissions that go nowhere is that the reasons they go nowhere are always interesting, and they also help me better understand the cases where patches come in and are accepted.
Sometimes someone submits a patch without offering a clear explanation of why the patch would be useful, and when questioned by the developers, the person offers vague or hypothetical explanations. Something like that happened recently when Matthew Garrett submitted a patch to disable a running kernel's ability to detect whether it was running entirely open-source code.
Specifically, he wanted to be able to load unsigned modules at runtime, without the kernel detecting the situation and "tainting" itself. Tainting the kernel doesn't affect its behavior in any significant way, but it is extremely useful to the kernel developers, who typically will refuse to chase bug reports on any kernel that uses closed-source software. Without a fully open-source kernel, there's no way to know that a given bug is inside the open or closed portion of the kernel. For this reason, anyone submitting bug reports to the kernel developers always should make sure to reproduce the bug on an untainted kernel.
Matthew's patch would make it impossible for developers to know whether a kernel had or had not been tainted, and this could result in many wasted hours chasing bugs on kernels that should have been tainted.
So, why did Matthew want this patch in the kernel? It never was made clear. At times he seemed to suggest that the patch was simply a way to avoid having users complain about their kernel being tainted when it shouldn't have been. At one point Ben Hutchings suggested that Matthew might want to allow third parties to sign modules on their own for some reason.
But as no one was able to get real clarity on the reason for the patch, and as tainting the kernel is traditionally a good way to avoid chasing down bugs in closed-source code, none of the developers seemed anxious to accept Matthew's patch.
Zack Brown is a tech journalist at Linux Journal and Linux Magazine, and is a former author of the "Kernel Traffic" weekly newsletter and the "Learn Plover" stenographic typing tutorials. He first installed Slackware Linux in 1993 on his 386 with 8 megs of RAM and had his mind permanently blown by the Open Source community. He is the inventor of the Crumble pure strategy board game, which you can make yourself with a few pieces of cardboard. He also enjoys writing fiction, attempting animation, reforming Labanotation, designing and sewing his own clothes, learning French and spending time with friends'n'family.
