linux-kernel - Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

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]

Date:	Sun, 15 Jul 2007 16:22:54 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Jeremy Maitin-Shepard <jbms@....edu>,
	"Huang, Ying" <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:

> On Sunday, 15 July 2007 21:23, david@...g.hm wrote:
>> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
>>
>>>>>> I think this is far more complicated then it needs to be.
>>>>>>
>>>>>> it sounds like it should be possible to do the following
>>>>>>
>>>>>> 1. figure out what pages should be backed up (creating a data structure to
>>>>>> hold them)
>>>>>
>>>>> That should be done after step 2, because the memory contents can change
>>>>> in this step.
>>>>
>>>> no, this needs to be done by the main kernel, becouse only it knows how to
>>>> find this info. the kernel that you kexec into could be very different
>>>> (including different versions) and the ways to identify this data is not
>>>> part of any existing API
>>>
>>> If the memory contents changes in step 2, then the information collected by
>>> the main kernel will be inaccurate.
>>
>> why would the memory use change when the new kernel is run? is it becouse
>> of whatever it does to the devices for the hand-off?
>
> Yes, I think so, although I'm not sure, because I don't know what happens to
> devices during a "normal" kexec.

is this  a matter of running some test to find out, or is this a question 
for the kexec implemantors?

>>>> during the wakeup stage, I thought you said that al that was needed was to
>>>> feed the suspend image to /dev/suspend and the kernel in the suspend image
>>>> would re-probe, or otherwise re-initialize all the devices it needs. am I
>>>> misunderstanding this?
>>>
>>> Perhaps.  Currently, the hibernated kernel will run device_resume() after
>>> the restore, which is not exactly compatible with what kexec does.
>>
>> but kexec isn't needed during the restore process, is it?
>
> Generally, it's not needed.  _However_, the current handling of devices is
> such that:
> (a) hibernated kernel uses device_suspend() to put them into low power states
>    and creates the image
> (b) hibernated kernel uses device_resume() to get devices back to work and
>    saves the image
> (c) during the restore the boot kernel loads the image and uses
>    device_suspend() to prepare devices for the "old" kernel
> (d) hibernated kernel gets control and uses device_resume() to get devices back
>    to work.
> Now, if you use kexec instead of (a) and (b), then whatever it does to devices
> is generally incompatible with the device_resume() in (d) (because, for
> instance, some device driver's .resume() routine may expect some data to be
> saved by the corresponding .suspend() at specific locations).

ok, this means that the resume operation is not a solved problem (at least 
for the kexec process)

now, one possible approach to this (and this may be what Ying Huang it 
thinking of) would be to have the restore process be

1. boot the normal kernel with a dummy userspace, initializeing all 
devices

2. kexec to the hibernate kernel

3. the hibernate kernel's userspace overwrites all memory from the 
origional system that was saved

4. kexec from the hibernate kernel back to the origional kernel

the ugly part here is the need for the dummy userspace in step #1 so that 
it doesn't try to access the wrong things.

now, it may be that the kernel boot in step 1 doesn't need to be able to 
initialize all drivers for things to work in step 4, in which case things 
are much simpler (but you still may need the three kernel hop so that the 
final kernel is running in the same addresses that it started in.

David Lang
-
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/