A software suspend decision point [LWN.net]

The relative calm which has settled around the software suspend subsystem may be about to come to an end. This part of the kernel, which has never worked to everybody's satisfaction, remains subject to different ideas of how the problem should be solved.

Pavel Machek's user-space software suspend patch was covered here in September. Pavel has now posted a new version of the patch with a request that it be merged for 2.6.16. The user-space approach is, clearly, the way Pavel thinks that software suspend should go. Beyond getting some code out of the kernel, this approach makes a number of add-on features, such as graphical displays, image compression, image encryption, network-based suspend, etc., easier to implement. If you want to hang a big pile of features onto the suspend mechanism, you eventually have to get into user space.

One of the first responses came from Dave Jones, who said:

Just for info: If this goes in, Red Hat/Fedora kernels will fork swsusp development, as this method just will not work there.

The main issue is the fact that the user-space approach uses /dev/kmem to repopulate memory at resume time. Red Hat and Fedora kernels do not allow memory to be overwritten in this way; there are no other applications which need that capability, with the exception of rootkits. Allowing user space to overwrite arbitrary physical pages is, to Dave, not worth it, no matter how many software suspend features it enables. Says Dave: "I'll take 'rootkit doesnt work' over 'bells and whistles'."

Nigel Cunningham, the author of the Suspend2 patches, also has some thoughts on the matter. He has been busily cleaning up the suspend2 patches with an eye toward making them more palatable for merging into the mainline. It turns out that Nigel has a set of 225 patches which he will soon make available. Since few people have seen the new patch set, it's not clear what sort of reception it will get. It can be said, though, that 225 patches is a large pile of code. Anybody trying to get a patch set of that size merged needs to have some fairly convincing arguments in hand.

At some point, Nigel's code mountain will become available, and some sort of decision will have to be made. Software suspend could be transformed into suspend2, or moved partially to user space. Or it could be left more-or-less as it is now. These are three very distinct choices - especially as nobody wants to see a repeat of the situation where the mainline kernel supported more than one software suspend implementation. With luck, when the dust settles, Linux will have a more featureful and reliable software suspend implementation than it does now. But expect some interesting discussion between now and then.

(Log in to post comments)

A software suspend decision point

Posted Nov 17, 2005 10:27 UTC (Thu) by lacostej (guest, #2760) [Link]

I believe the user land swsuspd will end in, in particular because it makes so few changes to the kernel. It's probably still a long way to have a fully functional user code. But I would hope that if the swsusp user land goes in, maybe Nigel can join with Pavel for the missing user land features.

And now if NVidia could move their @$$es to support ACPI in their drivers...

A software suspend decision point

Posted Nov 17, 2005 22:28 UTC (Thu) by iabervon (subscriber, #722) [Link]

It seems to me like it would be sufficient to block rootkits to have a sysctl that permanently disables /dev/kmem; then Red Hat could poke it when it decides you're not resuming an image and rootkits wouldn't be able to use it. Anything running at that point is loaded out of the kernel or initrd image, and an attacker that could get something to run then could just as easily get it to run inside the kernel. The security properties of early userspace are somewhat special, and it's not like you'd want to resume an image under ordinary conditions.

A software suspend decision point

Posted Nov 18, 2005 2:59 UTC (Fri) by brouhaha (subscriber, #1698) [Link]

Can't SELinux (which Fedora Core enables by default) be configured with appropriate security contexts so that only the user-space software suspsend program is allowed to write to /dev/kmem, but arbitrary code running as root cannot?

Without SELinux or something similar, if malware manages to run as root (possibly due to a privilege escalation exploit), you've already got VERY serious problems, and the inability to write to /dev/kmem doesn't restrict the malware's potential for wreaking havoc by very much.

And unless I'm missing something, blocking writes to /dev/kmem doesn't accomplish much unless you also block writes to /dev/mem. At one time there were a lot of things that wrote to /dev/mem, including the X servers; I don't know whether they still do. A few years ago I routinely used programs that wrote to /dev/mem to test various hardware under development, as well as a user-space ECC scrubbing program, but I haven't done either on Fedora.

Years ago I tried to push a suggestion to put special files in /proc/pci to allow access to PCI memroy regions, but a bunch of idiots thought that somehow that was MORE dangerous than writes to /dev/mem. Sigh.