Messages in this thread | | | Date | Thu, 2 Feb 2006 11:16:26 +0100 | From | Pavel Machek <> | Subject | Re: [ 01/10] [Suspend2] kernel/power/modules.h |
| |
Hi!
> > Still our approach is quite different to yours. We are focused on keepeing > > the code possibly simple and non-intrusive wrt the other parts of the > > kernel, whereas you seem to concentrate on features (which is not wrong, > > IMO, it's just a different point of view). We're moving towards the > > implementation of the features like the system image compression and > > encryption, > > graphical progress meters etc. in the user space, which has some > > advantages, and I think this approach is correct for a laptop/desktop > > system. > > > > Its limitation , however, is that it requires a lot of memory for the > > system memory snapshot which may be impractical for systems with limited > > RAM, and that's where your solution may be required. > > I'm more concerned about the security implications. I'll freely admit that I > haven't spent any real time looking at your code, but I'm concerned that the > additional functionality made available could be used by viruses and the > like. I'm sure you'd have to be root to do anything, but how could the > interfaces be misused?
In vanilla kernel userland suspend has no security implications: root can just do what he wants in /dev/mem, anyway.
In fedora kernel, userland suspend can be [miss]used to snapshot an image, modify it, and write it back. Fortunately, this is going to take *long* time so people will notice. [Interface changed on DaveJ's request, now we have separate device, we no longer mess with /dev/mem]. And similar problem exists in suspend2 -- malicious graphical progress bar could probably modify memory image on disk.
> > In conclusion, I see the room for both, as long as the do not conflict, so > > could we please bury the hatched and start working _together_? > > I didn't realise I was holding one :). I'm not sure that I agree that there's > a need for both, but I have no desire whatsoever to act an any sort of nasty > way. All I want is to help provide Linux users with stable, reliable, > flexible and fast suspend-to-disk functionality.
Please take a look at current -mm series. It has everything neccessary for your goals. Pavel
-- Thanks, Sharp! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |