A software suspend decision point
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:
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.
| Index entries for this article | |
|---|---|
| Kernel | /dev/kmem |
| Kernel | Software suspend |
Posted Nov 17, 2005 10:27 UTC (Thu)
by lacostej (guest, #2760)
[Link]
And now if NVidia could move their @$$es to support ACPI in their drivers...
Posted Nov 17, 2005 22:28 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Nov 18, 2005 2:59 UTC (Fri)
by brouhaha (subscriber, #1698)
[Link]
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.
Posted Nov 20, 2005 0:12 UTC (Sun)
by mikov (guest, #33179)
[Link] (1 responses)
Posted Nov 29, 2005 20:39 UTC (Tue)
by barrygould (guest, #4774)
[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.A software suspend decision point
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
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?
A software suspend decision point
How does suspend deal with hardware configuration changing between suspend and restore ? Does it check, or does it crash ?A software suspend decision point
On Fedora 4, my Dell D800 freezes if I try to resume from software suspend if my wireless card is not in place (if it was in when I suspended).A software suspend decision point