Kernel release status [LWN.net]

The current development kernel is 2.6.0-test7, which was released by Linus on October 8. Changes this time include a bunch of janitorial work, some IDE driver updates, a new filesystem mount option parsing scheme, a change to how module array parameters are declared, some video for Linux updates, an ACPI update, an XFS update, a reserved system call for the vserver project, and lots of fixes. See the long-format changelog for the details.

As part of the announcement, Linus has stated that he is tightening up the criteria for accepting patches.

The more interesting thing is that I and Andrew are trying to calm down development, and I do _not_ want to see patches that don't fix a real and clear bug. In other words, the "cleanup and janitorial" stuff is on hold, and -test8 and then -test9 should be for _stability_ fixes only.

The current stable kernel is 2.4.22; the last 2.4.23 prepatch was 2.4.23-pre6 on October 1.

(Log in to post comments)

vserver

Posted Oct 10, 2003 10:02 UTC (Fri) by AnswerGuy (guest, #1256) [Link]

It's nice to see someone working on a lightweight server virtualization system for Linux. Something between the BSD "jail()" system call and UML or some sort of (commercial) VMWare system. It's also nice to see that these additional features will have a neglibible performance impact.

It's alarming to see these pages blithely refer to the existing chroot() system calls as secure and "irreversible" since I've seen numerous code examples to the contrary. I realize that they are may just be glossing over some details since they talk more about the Linux capabilities (still a misnomer, they are "privileges" like VMS not true capabilities like EROS, KEYKOS, etc). However, the notion that chroot is secure *with* the appropriate "cap" bits removed is less egregious, if still a tenet of faith.

I only glanced over the vserver pages so I'll have to read the code, docs and patches in more detail; but it looked like they were talking about several system calls that would be needed so it's odd that Linus only reserved one for them. I'm sure they'll all work that out.

I'm not sure this is the right implementation, but it could be useful work it it's done right. I like the basic idea: chroot, limit root caps, eliminate visibility of processes to sibling contexts, limit access to specific networking interfaces (though I think it should be possible to assign multiple IP addresses per "jail" (vserver) --- even as I'm hard pressed to offer a compelling need to do so).

Basically this just might help solve the problem of running NTP, caching and/or subdomain DNS, DHCP, tftpd, and a few other relatively trivial (computationally) little services on a single box while limiting the risk to any of them getting compromised.