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:	Sat, 14 Jul 2007 00:12:04 -0700 (PDT)
From:	david@...g.hm
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	"Huang, Ying" <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	Jeremy Maitin-Shepard <jbms@....edu>,
	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 Fri, 13 Jul 2007, Rafael J. Wysocki wrote:

>> remember release early, release often (with something that functions)
>>
>>>> fo rthe current stage where we are trying to make things work don't worry
>>>> about packaging everything tight with initrd and re-useing partitions or
>>>> kernel images. once everything is working reliably then it's time to look
>>>> at useing the same kernel for multiple functions, writing to a partition
>>>> that's i use for other things, etc
>>>
>>> I don't agree.  You need to think of many limitations in advance, because
>>> they need to be taken into consideration in the design.
>>>
>>> Otherwise we'll end up with something that will need to be bandaided like the
>>> freezer. :-)
>>
>> on the other hand, worrying about all the possible ways to do things can
>> paralize you.
>>
>> the big advantage of the kexec approach is that the new userspace that's
>> setup with the new kernel can do _anything_.
>
> No, it can't.  For example, it can't access filesystems mounted by the
> hibernated kernel, or they may get corrupted after the restore (if they are
> journaling, it can't even read from them).

it's only ext3 that has this bug when mounting a fileystem read-only 
AFAIK.

> Which reminds me of one more issue, which is that the image-saving kernel
> won't be able to use these filesystems either, so its modules and user space
> will have to be available from somewhere else (like a RAM disk or dedicated
> partition).  So things get ugly.

another reason to go ahead and make a dedicated no-module kernel for the 
hibernate phase ;-)

> Apart from this, the new kernel's user space cannot blindly modify swap space
> that might be in use by the hibernated kernel.

with swap space you have two options

1. free it up (to a swap file if needed) and don't worry about it

2. try and ensure that nothing else on the system attempts to use the swap 
partition until you reboot.

#2 is failure prone, #1 would be more reliable.

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/