Re: [ 01/10] [Suspend2] kernel/power/modules.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux