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 [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]
