lkml.org 
[lkml]   [2006]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
    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@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 13:09    [W:4.235 / U:0.220 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site