lkml.org 
[lkml]   [2006]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
Date
On Feb 12, 2006, at 07:06, Alon Bar-Lev wrote:
> Kyle Moffett wrote:
>> Why the hell would you even _want_ to encrypt data in RAM? If you
>> have a secure OS install and a passworded screensaver that starts
>> before suspend, then there is _nothing_ an attacker could do to
>> the contents of RAM without hard-booting, which would just
>> completely erase it, or without extremely specialized hardware and
>> expertise. Picking up a machine suspended to RAM is just as
>> secure as picking up one that is on, no more or less.
>
> I guess you are not a security aware user... A machine that is
> turned on is *MUCH* less secured than a machine which is turned off
> and have its disks encrypted. We can start argue on this issue
> too... But I won't cooperate...

Where is your proof? This is quite true for a machine on a
_network_, but my suspended laptop isn't. You say that I am not a
security aware user and that therefore you are automatically right,
but it doesn't make it so. What is the practical vulnerability in my
laptop's suspend-to-ram, given that it automatically locks all VTs
and X when sleeping? Don't you *dare* say "somebody could attach a
hardware debugger and read your data out of RAM", because I just
don't see that happening in any reasonable situation, there are too
many obstacles to doing that with a _laptop_, the first of which is
just that it's impossible to take the damn thing apart when it's on
without disconnecting massive amounts of critical wiring. Even if
that _is_ a risk-case for you, it's not the use-case we should
optimize suspend for!

>>> And another fact: Suspend-to-RAM implementation can be derived
>>> form suspend-to-disk but not the other way around.
>>
>> No, the two are _entirely_ independent. Suspend-to-RAM does not
>> need to copy memory at all, whereas suspend-to-disk requires it.
>> That very fact means that suspend-to-RAM is orders of magnitude
>> faster than suspend-to-disk could ever be, especially as RAM gets
>> exponentially larger.
>
> Well... I see you already planned the implementation and have all
> figured out... But the fact is that suspend-to-RAM can be
> implemented by suspend-to-disk without actually store the memory to
> external device...

Right, the process goes something like this pseudocode:

put_devices_to_sleep(); /* [1] */
if (suspend_to_ram) {
call_firmware_suspend();
} else {
atomically_freeze_state();
wake_devices_up();
store_state_to_devices(); /* [2] */
put_devices_to_sleep();
switch(mode) {
SUSP_SHUTDOWN: shutdown();
SUSP_REBOOT: reboot();
[.......................]
}
}

Remind me again why we should implement suspend-to-RAM as part of
suspend-to-disk? Especially since the _only_ shared functionality is
[1] which is already separated out for other reasons. A lot of
people also seem to want to initiate and control all of [2] in
userspace, whereas the suspend-to-RAM case needs just one syscall.

> But hay... You can implement and maintain two separate solutions...

You still have yet to prove that suspend-to-RAM and suspend-to-disk
have anything to gain by being wrapped in a big if statement.

>> No, suspend-to-ram is for people who need instant response times,
>> suspend-to-disk should be an extension or simplification of
>> "Freeze a process tree and all associated system status so we can
>> completely give up the hardware for a while". IMHO, the fact that
>> both are called "suspend" is just due to historical quirk as
>> opposed to any real similarity.
>
> Again... This is a matter of implementation... I believe that one
> complete suspend implementation can suite both disk and RAM... The
> only difference is if you write the state to external storage, and
> how you play with APM. So there is a good reason why both are
> called "suspend".
>
> I don't claim that virtualization approach is not appropriate, and
> in the future suspend may use this in order to create its snapshot,
> and maybe, as you say, you may get suspend-to-RAM in-kernel and
> suspend-to-disk in user-space by dumping each process's container
> into a file (I don't know what you do with graphics and caching...
> but let's assume you have solution for all).
>
> Let's see what happened so far:
>
> First we had swsusp... For many people it did not work, so Suspend2
> was developed, but was not merged mainly because it had too many UI
> components in-kernel.

Actually, I seem to recall that even before _either_ of those were
working decently a bunch of modern hardware had good suspend-to-RAM
support.

> Then comes the micro-kernel approach to convert swsusp into
> uswsusp... Suspend2 which is stable now cannot be merged since it
> violates this idea. So users will not get a proper merged solution
> for at least one more year.
>
> Now, you come with a different solution (virtualization), so let's
> delay suspend feature for how long? At least two years?

Personally, I really don't care if you (or whoever) wants to merge an
intermediate suspend-to-disk/software-suspend implementation. I
think it would be helpful on a lot of laptops where suspend-to-RAM
doesn't work or chews battery. But I _really_ don't want to see
somebody trying to patch suspend-to-RAM/hardware-suspend into that mess.

> We need (and can get) suspend to work *NOW*,

It does work now, suspend-to-RAM/hardware-suspend has been working
perfectly on my laptop for a long time (modulo a couple powerbook USB
bugs that crept in recently and got removed). IMHO, a modern laptop
that doesn't support suspend-to-RAM is a broken design, although I
realize that it happens all too often.

> laptops are being more and more common... People expect to have
> this ability in a modern operating system, they don't care if it is
> implemented in kernel or in user-space, they also don't care if you
> change it along the way... And if in the future Linux will be pure
> virtual machine, all will be happy.... And use it... But please
> consider offering a working solution *NOW*.

On this I do agree, but _please_ don't muck with my suspend-to-RAM
along the way because of some egotistical "We are new-fancy-kernel-
software-suspend, resistance is futile" type thing, ok? Suspend-to-
RAM/hardware-suspend and suspend-to-disk/software-suspend are two
_completely_ different things and should not be treated the same at all.

Cheers,
Kyle Moffett

--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare



-
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/

\
 
 \ /
  Last update: 2006-02-12 17:35    [W:0.304 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site