linux-kernel - Re: [SUSPECTED SPAM] Re: [linux-pm] 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: <4C09C1D5.2030603@crca.org.au>
Date:	Sat, 05 Jun 2010 13:17:41 +1000
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Maxim Levitsky <maximlevitsky@...il.com>
CC:	Pavel Machek <pavel@....cz>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	TuxOnIce-devel <tuxonice-devel@...onice.net>
Subject: Re: [SUSPECTED SPAM] Re: [linux-pm] Proposal for a new algorithm
 for reading & writing a hibernation image.

Hi.

On 05/06/10 11:16, Maxim Levitsky wrote:
>
>> If the memory it writes to isn't protected, there'll be no recursive
>> page fault and no problem, right? I'm imagining this page fault handler
>> will only set a flag to record that the page needs to be atomically
>> copied, copy the original contents to a page previously prepared for the
>> purpose, remove the write protection for the page and allow the write to
>> continue. That should be okay, right?
> I think so, although I have no experience yet to comment on such things.
> Despite that I think you might run out of 'page previously prepared for
> the purpose'
> However you can adopt a retrial process, like you do today in tuxonce.
> Just abort suspend, and do it again.

Yeah. I'm expecting that it will be reasonably predictable - at least 
ballpark. I guess there's only one way to find out...

>>> Of course the sucky part will be how to edit the page tables.
>>> You might need to write your own code to do so to be sure.
>>> And this has to be arch specific.
>>
>> Yeah. I wondered whether the code that's already used for creating page
>> tables for the atomic restore could be reused, at least in part.
> This is very dangerous.
> The code might work now, and tomorrow somebody will add a code that does
> memory writes.
> The point is that you must be sure that there are no recursive faults,
> or somehow deal with them (this is probably too dangerous to even think
> of)

That shouldn't be too hard - after all, we're going to know what memory 
we're using to record the info. As long as we don't do anything silly 
like protecting our own data, we should be right.

>>> Since userspace is frozen, you can be sure that faults can only be
>>> caused by access to WO memory or kernel bugs.
>>
>> Userspace helpers or uswsusp shouldn't be forgotten.
> This is especially bad. because a fault in userspace will mean swapping.
> You won't get away with custom page fault for this.
> You could assure before suspend that all relevant userspace is not
> swapped, or forget about userspace, because its minor thing compared to
> speed increases of full memory write.

Mmm, but existing userspace helpers for TuxOnIce are carefully designed 
so everything is in memory before we start work, and so that nothing is 
done which will compromise the integrity of the image. I assume the same 
applies to uswsusp. I'm more concerned just to make sure that we don't 
forget to modify the page tables for these userspace processes (at least 
the TuxOnIce ones) so that any modifications to kernel memory made while 
in their process context are also caught.

Regards,

Nigel
--
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/