Slashdot Mirror
Drive-By Contributors to the Linux Kernel
eldavojohn writes "There's an interesting post over at the Kernel Trap that focuses on a man's attempt to find out how many one-time contributors Linux averages per release. Although imperfect due to some obvious unavoidable flaws, he got a few dirty numbers of 'never seen from agains' in the commits from patches 2.6.11 through 2.6.25 and the numbers are: {63, 148, 128, 92, 96, 122, 137, 140, 135, 95, 136, 153, 179, 179, 304}. This makes sense as another reader, Greg KH, pointed out that the distribution curve is tilted towards one-hit contributions, 'the distribution of all of our users are: 50% only contributed 1 patch; 25% contributed 2; 12% contributed 3; 6% contributed 4 and so on ...'"
How long til we get Jack Thompson on the case? Drive-bys and other kernel related violence is just not on! ~
Caesar si viveret, ad remum dareris.
There doesn't seem to be a lot of room for a web of trust here. I wonder how hard it would be to inject some sort of extremely non-obvious race condition hidden in a large and useful patch that just so happens to let you execute arbitrary code?
If you were found out, you could just claim, plausibly, that you hadn't seen the possibility of the race. Or maybe just be a one-time contributor so there is no way to track you down if the hole is discovered.
Well when you think about it, 1 patch just happens to be the number that most people will use. For example, a hardware business may put in one patch to get a device to work, a software company may put in one patch to make other things work, an individual may put in one patch to fix an obvious bug, etc. The kernel, though needed is not what the end-user generally uses, so for the most part it is in the background as a stable kernel should be, making it less of a chance someone would find many bugs to have to fix.
Taxation is legalized theft, no more, no less.
My own confusion as to the meaning of "drive by" in this context did make me wonder about ease of contribution.
What if there were a bifurcation or distribution of the bug-fixing/feature-adding problem? This may be really stupid, but I imagine a situation where testers go through finding things that are wrong or where they go wrong, then submit that bit of code.
On top of this, there is a system which grabs the trace and shows the bit of code where everything got derailed, and in other panes the stuff it called to, so anybody could look over the "offending" code, without having to be intimately familiar with the kernel or the library or whatever, since it is all laid out for them. Then, people can tinker with the code and submit them for (automatic, since you know what to look for) testing, maybe leave comments on the ticket to help others' or as a group try to figure it out.
I don't have time to wade through mountains of kernel code looking for bugs, but I would be more than willing to look over a (relatively) small bit of code in a collaborative fashion to see if I pick up on something others had missed.
Nice to see my name in 2.6.25 :)
I submitted a workaround for a buggy USB device a few months ago, which was my first patch after using linux for more than 10 years. Usually when I find a problem in the kernel it's either already been fixed in a later version, or it looks too complicated for me to risk wasting my time on. I would bet that a lot of my one-off colleagues have had the same experience.
F0 07 C7 C8
... whenever I've tried to submit a patch, it's a nightmare of process. Make sure you have the latest build, use the right diff tool, package it the right way, submit it to the right place, get the attention of the right person. Even then, you have to convince whomever that your patch is actually needed (are you sure you have the latest code, I'm not convinced that this is a real bug), and that your code doesn't stink -- "not invented here" is a huge problem.
I predict a record number of AC posts on this article.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
I have been thinking of a single contribution to the kernel myself. I would like to see a link somewhere in /proc that points to the location of kernel source code used to build the currently running kernel. This would remove the need to the current hacks of using a link in /usr/src/kernel that may or may not point to the correct kernel source. This would be used by scripts that build kernel modules for code that is not in the normal kernel.
If not a link, then a file whose contents is a file (somewhere in /proc) containing the pathname would also provide a similar capability.
The real "Libtards" are the Libertarians!
That's not a very good example. Hacking a CVS repository and adding a relatively easy to detect root exploit isn't how you'd want to go about this. It's far too likely to get noticed.
As the parent poster mentioned, you'd ideally want to submit a fairly large patch that does something useful (fixes a bug, adds a minor feature), but whicvh itself contains an exploitable bug.
The trick would be in making the submission large enough and the bug subtle enough that it just skates past review. Of course, it'd be *much* easier to insert bugs into any other Linux project, rather than the kernel. Not as much exposure to ultimately exploit, but there are quite a few executables and libraries that nearly every Linux system uses.
I think this is a very good idea as well. Right now I wish I had mod points. The kernel is just massive code-wise, not to mention there are tons of legacy bits of code that can be reduced, or just removed, or rewritten but people don't have the time to hunt them all down.
Quite frankly, I'd love to see professors assign this sort of thing as homework to their students. Grab a piece of OSS, and squash a bug. Or give them a reasonable size chunk of code and have them review it.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I think that would be a very interesting statistic.
G.
I was even going to call out the Debian OPENSSL debacle as an example, but I figured they'd had enough grief over it already.
Sorry if someone already said this, but here's what I think: All you have to do is write a patch that gets in *once* and you can forever brag about how your code is in the Linux kernel.
Property is theft.
The Internet is a wide open place. Software testing is inadequate. I'm sure there is no way you could possibly have known that when combined with that patch from the florist in Scotland, your code could possibly overwrite a few bytes of memory if called with an unlikely sequence of parameters. Whoops, I clobbered the userid? How silly of me.
Alternatively, accomplish the same thing via 2+ patches to 2+ projects which are likely to be used together. One patch against httpd + one patch against php = potential for a lot of mischief. Its not hard to fit a key to a lock when you're allowed to modify both the key and the lock to suit your tastes.
Help poke pirates in the eyepatch, arr.
These stringent development procedures are precisely what make the Linux kernel that robust. It's not the code, it's the coding procedures. Your patches should be documented, easy to review, QA, and apply. I wouldn't accept patches from a sloppy developer who wouldn't be bothered following the appropriate procedures.