KS2010: Kernel.org update

Kernel.org admin John Hawley showed up at the 2010 Kernel Summit looking a bit ragged. He had hoped that the Summit would be a good time to slip in a system upgrade; after all, most of the users of the kernel.org master machine would be otherwise occupied. But the upgrade went wrong, files disappeared, and John was up rather later than he had expected. Things were working by the time his slot came around, though; all that was left was some residual grumpiness over the thousands of commit messages that the system had dumped into developers' mailboxes.

Some time was spent describing the kernel.org system. The master machine ("hera") sits in the middle; that's the system that developers interact with. There are two outlying systems handling database-driven web tasks - wikis, bugzilla, etc. Four systems handle git and the rest of the web serving load, and four more (the beefiest of them all) run mirrors.kernel.org. Most of the machines are spread out in the western US, but a few are in northern Europe.

Ted Ts'o asked about the possibility of putting machines into Asia. There have been requests for mirrors there, but it is hard to find the hosting. In particular, John said, once he talks about the sort of bandwidth that kernel.org uses, potential hosting donors tend to disappear. Getting equipment into place can also be a pain, since kernel.org's computers are all donated; shipping them to other countries can lead to customs bills that kernel.org is not in a position to pay. It won't be possible to put systems into China in any case due to the Great Firewall, but China is where a lot of the demand is. In summary: it's desirable and possible, but it has not proved practical so far.

In general, kernel.org is doing OK with donations. It's apparently been getting easier to find donations of equipment and money.

What about IPv6 support? There's evidently some software work that needs to be done. It will happen before too long.

There were questions about the security of kernel.org. The physical security of the machines is quite good, there are no worries there. Kernel.org did suffer a compromise recently, the result of credentials which were stolen from a nearby compromised machine. There were some concerns expressed about the security of Linus's tree, but the answer is that there is not much to worry about. The dynamic web serving - the most likely source of a breach - is kept far away. Any corruption of the git repository on kernel.org would cause checksum mismatches and, thus, would be immediately noticed by Linus and others. Linus has two firewalls at home, to the point that he can't get into his own systems remotely. Should somebody break into his house, any corruption of his home repository would be noticed on the next push to master.

In summary: corrupting the tree would require compromising both Linus's house and kernel.org. Given an apparent lack of targeted attacks (the one compromise didn't seem to have anything to do with the kernel), there does not seem to be much reason to worry at this time.

Next: Development process issues.

Index entries for this article
Kernel	Development tools/Infrastructure

---

to post comments

KS2010: Kernel.org update

Posted Nov 3, 2010 21:32 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

The "It won't be possible to put systems into China in any case due to the Great Firewall," is odd. How does that make a difference, out of curiosity?

KS2010: Kernel.org update

Posted Nov 4, 2010 9:15 UTC (Thu) by Klavs (guest, #10563) [Link]

I'm guessing the firewall blocks the protocols that a kernel.org mirror would use to maintain the machine behind the "great" firewall.

KS2010: Kernel.org update

Posted Nov 3, 2010 23:15 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> Any corruption of the git repository on kernel.org would cause checksum mismatches and, thus, would be immediately noticed by Linus and others.

It could show up, not as a checksum mismatch, but as a "forced update". I noticed the system upgrade problem mentioned above as a "forced update" from e99d11d to 4193d91 (something like "e99d11d...4193d91 (forced update)"), and spent some time making sure that it was just "going backwards in time" and not something more obviously malicious.

There is another security barrier not mentioned above: most users do not build kernels directly from the kernel.org git repository (I would in fact guess most people get their kernels already compiled from the Ubuntu repositories), and even the ones that do will not build a new kernel all the time (they will build for instance one or two kernels per day at most). The exception being the kernel developers, which are also the ones who can notice odd things more quickly. This gives time for a malicious commit to be found before it spreads too much.