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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]