linux-kernel - Re: Proposal for a new algorithm for reading & writing a hibernation image.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BE82C4D.20404@tmr.com>
Date:	Mon, 10 May 2010 11:54:53 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Nigel Cunningham <ncunningham@...a.org.au>
CC:	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	TuxOnIce-devel <tuxonice-devel@...onice.net>
Subject: Re: Proposal for a new algorithm for reading & writing a hibernation
 image.

Nigel Cunningham wrote:
> Hi all.
> 
> Some discussions with Rafael a while ago (can't find the original 
> message now, sorry) got me thinking about whether there might be a 
> better way of writing a complete image of memory, particularly in the 
> context of KMS breaking existing TuxOnIce algorithms. I finally got 
> around to hammering out the algorithm last night, and thought I'd put it 
> out there for others to comment on, particularly since I'm no expert on 
> fault handling - it may be that what I'm thinking of is impossible on 
> the hardware we support.
> 
> The algorithm I'm thinking of trying to implement goes as follows:
> 
> When saving the image
> =====================
> 
> 1. Modify driver suspend and resume routines so that the freeing of 
> memory used for the storage of state is separated from restoring the 
> resume methods. This will allow us to get the drivers to save their 
> state prior to writing the image, without needing the memory allocated 
> for this purpose to be atomically copied.
> 2. Prior to writing any of the image, also set up new 4k page tables 
> such that an attempt to make a change to any of the pages we're about to 
> write to disk will result in a page fault, giving us an opportunity to 
> flag the page as needing an atomic copy later. Once this is done, write 
> protection for the page can be disabled and the write that caused the 
> fault allowed to proceed.
> 3. Write the entire contents of memory to disk.
> 4. Disable secondary CPUs (no need to do the driver suspend/resume 
> again) and atomically copy pages that faulted while writing the image.
> 5. Write atomically copied data to disk, giving a complete image on disk 
> of memory at the time of the atomic copy.
> 
> When loading the image
> ======================
> 1. Locate and allocate pages that can have data directly loaded (ie are 
> free now and used in the saved image). These will be loaded without an 
> 'atomic restore'.
> 2. For other pages:
>    As each page is loaded:
>    - Write protect existing data.
>    - If contents are the same as what is being loaded
>      Discard loaded version
>      If contents change after being write protected,
>      1. make a copy of unmodified version to later atomically copy back.
>      2. remove write protection
>    - If contents differ
>      1. set up atomic restore later
>      2. remove write protection
> 3. After loading memory and determining what needs to be atomically 
> restored:
> - Do drivers suspend, atomic restore as is done at the moment
> 
> The main difficulties I see with the above are - apart from not being 
> sure that I can achieve the above with fault handling - are:
> 
> 1. Memory requirements for the atomic copy wouldn't be known until the 
> point where we get to the atomic copy. I guess, though, that with most 
> things frozen, we'd expect the number to be reasonably consistent and 
> small.
> 2. We also need extra memory for the driver suspend at resume time. That 
> said, since it's not otherwise needed, it could be the same memory 
> that's reserved for doing I/O and for atomically copied data when 
> writing the image.
> 
> Are there other issues people can see that I might have missed?
> 
I doubt you "missed" considering compression, but you didn't mention it.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/