linux-kernel - Re: [PATCH] kexec based hibernation: a prototype of kexec multi-stage load

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] [day] [month] [year] [list]

Date:	Sat, 17 May 2008 18:59:58 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"Huang, Ying" <ying.huang@...el.com>, Pavel Machek <pavel@....cz>,
	nigel@...el.suspend2.net, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Kexec Mailing List <kexec@...ts.infradead.org>
Subject: Re: [PATCH] kexec based hibernation: a prototype of kexec multi-stage load

Vivek Goyal <vgoyal@...hat.com> writes:
>
> To me this idea also looks good. So control flow will look something
> as follows?
>
> relocate_new kernel:
> 	
> 	if (!preserve_context)
> 		set registers to known state.
> 		jump to purgatory.
> 	else
> 		goto jump-back-setup:
>
> jump-back-setup:
> - Color the stack.
>   move $0xffffffff 0(%esp)
>
> - call %edx
>
> kexec_jump_back_entry:
>
> - If 0 (%esp) is not -1
> 	image->start = 0(%esp)  //Re entry point of kernel B. Store it.
>   else
> 	We returned from BIOS call. Re-entry point has not changed
>         Do nothing.
>
> - Continue to resume kernel A

That logic has more conditionals then I like but it may in
fact be reasonable.  I don't have any fundamental objections
into making this a co-routine interface.

That said.  I think immediately implementing a coroutine interface
is a premature optimization.  Please let's work on call/return.
Then prototype the coroutine method of suspend to swap and see
how much time it saves us.

Honestly I will be surprised if time will be saved, as historically
at least the bottleneck in kernel startup time is initializing
hardware, and we need to essentially redo all of that initialization.

Eric

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