2.6.33 merge window part 1 [LWN.net]

By Jonathan Corbet
December 9, 2009

Linus began merging patches for the 2.6.33 development cycle on December 5. The merge window got off to a slow start, but then Linus began to make up for lost time; as of this writing, some 3900 changesets have been merged.

User-visible changes include:

The ftrace framework has seen a number of improvements, including the ability to trace multiple processes simultaneously, regular expression support in tracing filters, tracing of big kernel lock events, and tracing of accesses and modifications to arbitrary kernel variables.
Perhaps most significantly (for ftrace), the dynamic probes for ftrace patch set has been merged, allowing the placement of arbitrary tracepoints at run time. The "perf" tool has also been extended to be able to place and use dynamic tracepoints.
There are many other enhancements to "perf," including a new framework for benchmark suites, a command to record and analyze kernel memory allocations, and a generic scripting language hook set.
Eric Biederman's long quest to remove binary sysctl() support has finally made it into the mainline.
The recvmmsg() system call has been added.
The anticipatory I/O scheduler has been removed, in favor of CFQ which is seen as providing a superset of features.
The new, unified block I/O bandwidth controller has been merged.
The networking layer has gained support for TCP cookie transactions [PDF], a mechanism which allows faster, more secure, and more robust initiation of TCP connections.
The DRBD distributed block device has been merged.
New drivers:
- Boards and processors: ST-Ericsson U8500 boards, Marvell Dove (88AP510) system-on-chip CPUs, Palm Centro 685 phones, and CompuLab CM-T35 boards.
- Networking: TI High End CAN controllers, Intel Wireless MultiCom 3200 chips, Ralink rt2800 wireless chipsets, Microchip MCP251x SPI CAN controllers, Freescale MSCAN-based CAN controllers, and Solarflare SFC9000 10G Ethernet controllers.
- Sound: miroSOUND PCM20 radio tuners, Texas Instruments TPA6130A2 stereo headphone amplifiers, TI tlv320dac33 codecs, Asahi Kasei AK4113 and AK4671 codecs, WM8580 based audio subsystems on SMDK64xx systems, Wolfson Micro WM8711/L sound devices, and Raumfeld audio adapters.
- Miscellaneous: GRLIB APBUART serial ports, Oki MSM6242 realtime clock chips, and Ricoh RP5C01 RTCs.

Changes visible to kernel developers include:

There is a new unreachable() macro which can be used to mark code which will never be executed. Its main application is in macros like BUG().
New security module hooks, intended for pathname-based modules, have been added to check chmod(), chown(), and chroot().
There is a new RCU variant, called "tiny RCU," which is meant for non-SMP situations where memory footprint must be minimized.
printk_ratelimit() can, once again, be used in atomic context. (Note, though, that there are developers who would like to eliminate this function in favor of some sort of more local rate limiting).
The creation of nearly-identical tracepoints has been made significantly easier. TRACE_EVENT_TEMPLATE() has a syntax identical to TRACE_EVENT(), but it creates a template which can be used by the simpler DEFINE_EVENT() macro to create specific tracepoints. The code gets simpler, and, as a side benefit, the kernel gets smaller.

The merge window should stay open for at least another week; expect quite a bit more code to be incorporated for 2.6.33 before the window closes.

(Log in to post comments)

2.6.33 merge window part 1

Posted Dec 10, 2009 9:37 UTC (Thu) by wahern (subscriber, #37304) [Link]

Ugh. Now those who use chroot will have even more headaches to deal with.

For example, my portable arc4random--which uses sysctl(CTL_KERN, KERN_RANDOM, RANDOM_UUID)--will break. Requiring people to seed before the chroot happens, or requiring users to create device files in the chroot tree doesn't help; those things aren't required on other platforms.

One plus is that there'd be less kernel exposure in a chroot without either /proc or sysctl. And certainly in general removing code is good, though /proc has historically been riddled with kernel exploits; far more than sysctl ever produced. Indeed, the mere existence of /proc outside the chroot has its own problems, like exposing file descriptors--pipes, socketpairs--that would otherwise be unaddressable by other processes. Thus one of the strongest security characteristics--using descriptors as ad hoc "capability" tokens--is totally broken. File permissions aren't nearly as strong a security mechanism as the inability to reference the object.

2.6.33 merge window part 1

Posted Dec 10, 2009 9:55 UTC (Thu) by johill (subscriber, #25196) [Link]

"He then adds back a new wrapper which emulates the sysctl() ABI by way of /proc/sys. So any applications using sysctl() should continue to work, but the code dedicated to making it work is much reduced from what was there before."

I don't think that wrapper actually requires it to be mounted.

2.6.33 merge window part 1

Posted Dec 10, 2009 16:20 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

Correct. /proc does not need to be mounted simply compiled in for the
sysctl(2) support to work.

2.6.33 merge window part 1

Posted Dec 10, 2009 16:37 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

I still believe turning off sysctl(2) as scheduled in Documentation/feature-removal-schedule.txt at the end of next year is a good idea. Code that no-one cares about bit-rots in horrible ways.

A few comments.
arc4random prefers to use /dev/urandom and tries that first so even
inside a nicely setup chroot it will work.

sysctl was absolutely riddled with exploitable code, when I started working on it, and a hole was closed just a few weeks ago. It just happens that no one not even those who exploit kernel issues for the fame looked at the implementation details of sysctl.

I will agree that the sysctl format of only exporting simple integer and string values is much harder to exploit, and as such is a good idea.

As for the file descriptors they are not exposed to other users. The permissions on /proc/<pid>/fd/ are limited. Except for one esoteric corner case you can't do anything more with the file descriptors in proc than you could by attaching a debugger. Using file descriptors as ad hoc "capability" tokens is not broken in any way that I am aware of.

2.6.33 merge window part 1

Posted Dec 10, 2009 19:45 UTC (Thu) by spender (subscriber, #23067) [Link]

Rather than get into a discussion about private research vs public research, exploit writing vs vulnerability finding, etc, I'll just ask:
What's the CVE for the vulnerability that was fixed?

-Brad

2.6.33 merge window part 1

Posted Dec 10, 2009 20:29 UTC (Thu) by wahern (subscriber, #37304) [Link]

Neither mine nor the original in OpenBSD does this. FreeBSD's seems to do this, but that's still a fault all the same. It's very common to use /var/empty as the root directory.

Though, I'll admit then that Linux wouldn't be the first to break this behavior (if indeed it did, which it hasn't yet). I'll have to fix my apps to stir before any chroot.

As for /proc/$$/fd: take Apache as an example. Site A can access descriptors--specifically anonymous pipes--of site B. That the process for site A could theoretically attach itself to site B is beside the point. Typically both processes are running virtual machines and/or interpreters where debugging interfaces aren't available. Regular file routines, however, are usually available. Breaking out of a VM is significantly more difficult than coaxing a script to eval code.

Requiring a different process user for every site is impracticable, unless perhaps the kernel could provide ephemeral UIDs. Anyhow, you can drop ptrace capabilities, yet because of the growing necessity of /proc it's increasingly just as impracticable to not have /proc mounted.

With the rise of "cloud computing" (née SaS, née time-sharing systems), the notion that privileges are necessarily tied to persistent objects or system-wide credentials is short-sighted. The operating system should provide certain primitives and behaviors that allow applications to create ad hoc privilege systems enforceable by the hardware, e.g. the MMU. Solutions like SELinux, or any other system-wide _explicit_ access control, miss the mark entirely in almost every way imaginable.

2.6.33 merge window part 1

Posted Dec 19, 2009 10:48 UTC (Sat) by jengelh (subscriber, #33263) [Link]

>I still believe turning off sysctl(2) as scheduled in Documentation/feature-removal-schedule.txt at the end of next year is a good idea. Code that no-one cares about bit-rots in horrible ways.

And for where it matters, glibc could emulate sysctl() by going to /proc/sys instead.