lkml.org 
[lkml]   [2005]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: resuming swsusp twice
Hi!

> > I of course won't say that this cannot happen, but by design, the
> > swsusp
> > signature is invalidated even before reading the image, so
> > theoretically
> > it should not happen.
>
> Yes, I'd seen that happen on earlier swsusps, so I was quite suprised
> when it blew up like this.
>
> Perhaps the image should be more rigorously checked? I'm wishing that
> it would verify that the header and the image matched, after it finishes
> reading the image. For example, computing the hash
>
> MD5(header || image) (|| denotes "concatenate" in crypto pseudocode.)
>
> and storing that hash in a final trailing block. Additionally, of
> course, as soon as the resume has read the image it should overwrite the
> header; and the header should include jiffies or something along those
> lines to ensure that it won't accidentally have the same contents as the
> previous image's header.
>
> The hash doesn't have to be MD5; even a CRC should suffice I think...

Actually, what you want is "if filesystems are newer than suspend
image, panic" test. There is more than one way how that can happen.

Are you sure you did not do

suspend kernel 1
boot kernel 2
attempt to suspend kernel 2 but fail ("not enough swap space")
boot kernel 1 ("and successfully resume, corrupting data")

?
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-
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: 2005-07-16 16:07    [W:1.670 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site