Kernel development [LWN.net]

Brief items

Kernel release status

The current development kernel is 2.6.0-test10, finally released by Linus on November 23. This patch contains a month's worth of accumulated fixes for serious bugs, and not a whole lot else. Linus notes that there is still a problem associated with preemption out there; the kernel preemption code itself is likely not at fault, but some subsystem or driver out there somewhere is not being entirely preempt-safe. That problem had not been tracked down as of this writing.

The long-format changelog contains the details for the patches incorporated in this release.

Incidentally, -test10 has been dubbed the "stoned beaver" release.

Linus also laid out his thinking for the future:

I'm planning/hoping on basically turning this over to Andrew, and let him decide to make the final 2.6.0 or not. Timing-wise Andrew is apparently going to be off for a few weeks, so regardless of whether this turns out to be rock solid or not, we'll have a few weeks of final testing before that were to happen. Which means that I might still end up making a test11 if Andrew hasn't come back and we find something that warrants it.

Linus's BitKeeper tree holds a small number of additional fixes.

The current stable kernel is 2.4.22, but its time is coming to an end. Marcelo released 2.4.23-rc3 on November 21, with the idea that it would become the final release. Reality dictated otherwise, with the result that 2.4.23-rc4 came out on the 24th, and 2.4.23-rc5 on the 25th. The idea, of course, is that this one will become the final release; stay tuned.

Comments (none posted)

Kernel development news

BSD security levels for Linux

The Linux Security Module (LSM) patch was intended to enable the creation of a wide variety of security regimes for Linux systems. So far, the main user of the LSM functionality has been the NSA SELinux module. But there are signs that other security-oriented developers are beginning to make use of LSM to implement different approaches.

The latest such is the BSD Secure Levels patch posted by Michael Halcrow. This patch is intended to create something resembling BSD's secure level capability for Linux. Thus it implements an integer security level, which has useful values of zero to two. At level zero, the system functions as always - as if the module were not present at all. Zero is the default level, but the level can be raised (but not lowered) by writing the new value to /proc/seclvl.

At level one, a number of actions become disallowed, including:

Tracing the init process.
Modifying an immutable file.
Anything involving raw I/O to a device.
Network administration tasks.
Changing the user ID of a process.
Loading or unloading modules.
Writing directly to a mounted block device.
Writing to /dev/mem or /dev/kmem.
Changing the setuid or setgid bits of a file.

At security level two, a few additional actions are prohibited:

Changing the system time - but only if you are trying to set it backward.
Writing to any block device, whether mounted or not.
Unmounting a filesystem.

The "secure level" patch is thus a way of raising the bar for any potential attacker. At the higher levels, even a process with root privileges cannot make certain kinds of changes to the system. Normally, higher levels are forever; the only way to lower the secure level is to reboot the system. Note, however, that this module allows the administrator to include a small back door by specifying an executable that, when run, causes the secure level to be reset to zero. This feature may be useful for administrators who are converting a system over to secure level operation. Leaving the "emergency reset" option enabled permanently would be dangerously counterproductive, however.

Comments (4 posted)

Review: Linux Kernel Development

Writing books about the Linux kernel is hard. The subject matter is vast, complex, and highly technical. It also is very much a moving target;

today's kernel book becomes obsolete in a short period of time. So kernel authors have to pick their subject matter carefully, time things well, and enjoy their fifteen minutes of fame before somebody merges a patch and their words begin the inevitable slide into obsolescence.

The latest kernel book to hit the shelves is Linux Kernel Development by Robert Love. The goal of this book is perhaps best expressed by Andrew Morton in the foreword. He notes that kernel development has become increasingly complex as the kernel grows and scales to larger systems. That complexity increases the functionality and performance of the kernel, but it comes with a cost: the kernel is harder to understand than it once was.

I believe that this declining accessibility of the Linux source base is already a problem for the quality of the kernel, and it will become more serious over time. Those who care for Linux clearly have an interest in increasing the number of developers who can contribute to the kernel.

The purpose of this book is to help developers get to where they can make a contribution.

Linux Kernel Development covers a lot of ground. There are chapters on process management and scheduling, how system calls work, interrupt handling (but not device drivers in general), delayed work mechanisms, locking and mutual exclusion, timers, memory management, filesystems and the block layer, the page cache, kernel debugging, and more. This book, however, is just over 300 pages long, so it necessarily does not cover any of these topics in any great depth. Thus, for example, you will see what each of the inode_operations methods is, but there is little information on how to write one. Linux Kernel Development is a starting point which will prove useful to any developer trying to get up to speed with one or more kernel subsystems. Completing that process, however, will still require setting down the book and diving into the source.

That said, this book is truly a good starting point. After having perused the text on a particular subsystem, the reader will have enough background to be able to make sense of the source much more quickly than before. The presentation is clear, the writing is enjoyable to read^*, and the information is accurate and useful. Linux Kernel Development belongs on the shelf of any developer who is interested in kernel work.

One small complaint that one might make is that it is hard to figure out just which version of the kernel this book covers. The fine print on the back notes that it covers 2.6. Of course, the book was published in September, and now, at the end of November, the 2.6 kernel has not yet been released, so that statement is not entirely accurate. A suitably attentive reader can find places where the current kernel diverges from the text of this book - the listing of struct inode lacks the i_cdev field, for example. Kernel books will always tend to be like that, however; they are only completely accurate when they are out of date. Mr. Love appears to have timed things pretty well with this one; the differences between the text and the current development kernel are minimal - so far. For the time being, Linux Kernel Development is the best description of the structure and API of the 2.6 kernel available.

[Disclaimer: your reviewer is the co-author of a Linux Kernel book which could be seen as competing with Linux Kernel Development, though he sees the two as being entirely complementary. Buy Both.]

^*Though sprinkled with rather more footnotes that your reviewer might have preferred...

Comments (5 posted)

A last-chance kernel message dumper

If you have spent enough time working with development kernels, you may well have experienced the joy of a system panic which brings the system to a complete halt. Depending on the nature of the problem, you may find that the only information on what has happened is to be found on the system console. At that point, you may be reduced to trying to transcribe an oops listing by hand - if you are lucky. It may be that the information you really need has scrolled off the screen and is no longer available.

A useful tool for situations like this is kmsgdump; a version for 2.6.0-test9 has just been announced. This patch, which includes a scary amount of assembly code, does nothing until the system panics. At that point it jumps in and dumps the kernel message buffer to a diskette or parallel port. Later, when your system is running again, you can look over the output at leisure - or forward it on to somebody who knows how to interpret it. No more pen and paper required.

Comments (3 posted)

Driver porting

Driver porting series update complete

The promised update of the LWN.net Driver Porting Series is now complete; all of the articles should be current with the 2.6.0-test10 kernel. This series now consists of 37 articles covering changes in almost every kernel interface of interest to driver programmers. More content may be added in the future, but, with luck, another massive updating (for 2.6, anyway) won't be necessary.

Comments (2 posted)

Patches and updates

Kernel trees