LWN.net Logo

2.6.34 Merge window, part 2

By Jonathan Corbet
March 10, 2010
There have been nearly 1600 non-merge changesets incorporated into the mainline kernel since last week's summary; that makes a total of just over 6000 changesets for the 2.6.34-rc1 release. Some of the most significant, user-visible changes merged since last week include:

  • Signal-handling semantics have been changed so that "synchronous" signals (SIGSEGV, for example) are delivered prior to asynchronous signals like SIGUSR1. This fixes a problem where synchronous signal handlers could be invoked with the wrong context, something that apparently came up occasionally in WINE. Users are unlikely to notice the change, but it is a slight semantics change that developers may want to be aware of.

  • A new Nouveau driver with an incompatible interface has been merged; as of this writing, it will break all user-space code which worked with the older API. See this article for more information on the Nouveau changes. Nouveau also no longer needs external firmware for NV50-based cards.

  • The direct rendering layer now supports "VGA switcheroo" on systems which provide more than one graphical processor. For most needs, a simple, low-power GPU can be used, but the system can switch to the more power-hungry GPU when its features are needed.

  • The umount() system call supports a new UMOUNT_NOFOLLOW flag which prevents the following of symbolic links. Without this flag, local users who can perform unprivileged mounts can use a symbolic link to unmount arbitrary filesystems.

  • The exofs filesystem (for object storage devices) has gained support for groups and for RAID0 striping.

  • The LogFS filesystem for solid-state storage devices has been merged.

  • New drivers:

    • Media: Wolfson Microelectronics WM8994 codecs, and Broadcom Crystal HD video decoders (staging).

    • Miscellaneous: Freescale MPC512x built-in DMA engines, Andigilog aSC7621 monitoring chips, Analog Devices ADT7411 monitoring chips, Maxim MAX7300 GPIO expanders, HP Processor Clocking Control interfaces, DT3155 Digitizers (staging), Intel SCH GPIO controllers, Intel Langwell APB Timers, ST-Ericsson Nomadik/Ux500 I2C controllers, Maxim Semiconductor MAX8925 power management ICs, Max63xx watchdog timers, Technologic TX-72xx watchdog timers, and Hilscher NetX based fieldbus cards.

Changes visible to kernel developers include:

  • There has been a subtle change to the early boot code, wherein the kernel will open the console device prior to switching to the root filesystem. That eliminates problems where booting fails on a system with an empty /dev directory because the console device cannot be found, and eliminates the need to use devtmpfs in such situations.

  • The kprobes jump optimization patch has been merged.

  • The write_inode() method in struct super_operations is now passed a pointer to the relevant writeback_control structure.

  • Two new helper functions - sysfs_create_files() and sysfs_remove_files() - ease the process of creating a whole array of attribute files.

  • The show() and store() methods of struct class_attribute have seen a prototype change: the associated struct class_attribute pointer is now passed in. A similar change has been made to struct sysdev_class_attribute.

  • The sem lock found in struct device should no longer be accessed directly; instead, use device_lock() and device_unlock().

At "only" 6000 changesets, 2.6.34 looks like a relatively calm development cycle; both 2.6.32 and 2.6.33 had over 8000 changesets by the time the -rc1 release came out. It may be that there is less work to be done, but it may also be that some trees got caught out in the cold by Linus's decision to close the merge window early. Linus suggested that he might yet consider a few pull requests, so we might still see some new features added to this kernel; stay tuned.


(Log in to post comments)

Mount and symlinks

Posted Mar 11, 2010 11:53 UTC (Thu) by epa (subscriber, #39769) [Link]

The umount() system call supports a new UMOUNT_NOFOLLOW flag which prevents the following of symbolic links. Without this flag, local users who can perform unprivileged mounts can use a symbolic link to unmount arbitrary filesystems.
Is this fixing a security hole or is it a new feature?

Mount and symlinks

Posted Mar 11, 2010 15:15 UTC (Thu) by viro (subscriber, #7872) [Link]

That depends... If root is dumb enough to mount/umount something in user-modifiable parts of tree with users present, you are screwed anyway, symlink attacks or no symlink attacks. Just Don't Do It(tm), on any Unix.

If you are allowing non-root mounts, you need to be damn careful; it *is* possible to get it right as it is. Variant that doesn't follow symlinks makes some parts of that slightly easier; it's not a big simplification, but it makes sense and it is useful.

Whether your suid-root mount wrapper of choice is getting it right or not is a separate question, of course - all software sucks and all such.

It doesn't close any existing security holes (if nothing else, existing binaries behave as they used to) and it's not as if it was providing means for closing a hole that would be impossible to close without it.

So whether you call that fixing a security hole or not is up to you. Commit message is a bit too strong ("needed for" != "makes it easier to") and TFA is even stronger than that. The former hadn't been too far over the top and I didn't feel like editing it. As for the latter... questions to the article's author.

Here begins the countdown to wankers splashing out in force, screaming "coverup" and "conspiracy"...

Mount and symlinks

Posted Mar 12, 2010 11:12 UTC (Fri) by epa (subscriber, #39769) [Link]

Ah... I didn't realize this was talking about a suid-root wrapper for mount. I misunderstood the 'users who are allowed to perform unprivileged mounts' and thought it was talking about some kernel setting to allow non-root users to call mount(2).

So what this change really does is make it more straightforward to implement a secure suid-root wrapper for mount(2) in user space.

Mount and symlinks

Posted Mar 12, 2010 15:30 UTC (Fri) by nix (subscriber, #2304) [Link]

I thought that's what it was as well. I know Miklos eventually wants to be able to have random users call mount() and umount() for their own FUSE filesystems on mount points they own without relying on a setuid wrapper.

Mount and symlinks

Posted Mar 12, 2010 12:19 UTC (Fri) by spender (subscriber, #23067) [Link]

coverup
conspiracy

Al, please get over yourself.
Sincerely,
-Brad

2.6.34 Merge window, part 2

Posted Mar 16, 2010 11:12 UTC (Tue) by nye (guest, #51576) [Link]

Coincidentally I was just musing last night about whether it would be possible to do something like this VGA switcheroo. There are two things I'm wondering though:

To what extent is the unused device powered down? Are we looking at [near-]zero power consumption?

Also, how do you get the monitor to work with both devices; surely this can't involved reconnecting the cable?

2.6.34 Merge window, part 2

Posted Mar 18, 2010 10:40 UTC (Thu) by klaasjan (guest, #5492) [Link]

VGA switching is mostly implemented on laptops to save power (for instance on some current generation MacBook pro models). Since there is no user-connectable video cable, reconnecting is not required. Seems the hardware is capable to connect the active GPU to the screen output.

Seems this setup will be deprecated soon for the nVidia "Optimus" technology which allows a secondary GPU to render to the primary GPU's framebuffer without manual GPU switching.

2.6.34 Merge window, part 2

Posted Mar 18, 2010 12:51 UTC (Thu) by nye (guest, #51576) [Link]

Thanks for the clarification - hopefully this will lead to extremely low idle power consumption for general purpose graphics cards within a few years' time. This is important to me as the idle power consumption is a major factor in the decision of what hardware to buy - much more than its peak power consumption given that 99% of the time I'm not pushing the card to its limit, but still need that limit to be high for the other 1%.

Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds