Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel]Re: [ 00/10] [Suspend2] Modules support.)

[Alon Bar-Lev]

Kyle Moffett wrote:
> On Feb 12, 2006, at 03:51, Alon Bar-Lev wrote:
>> 2. Encrypt state - this allow you to be sure that your data is stored
>> encrypted. (Yes... You can encrypt the memory... but then you need a
>> whole initramfs clone in order to allow the user to specify how he
>> want to encrypt/decrypt).
> 
> 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...

>> 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... But hay... You can implement and maintain
two separate solutions...

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

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?

We need (and can get) suspend to work *NOW*, 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*.

Best Regards,
Alon Bar-Lev.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/