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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080516134024.GF6926@redhat.com>
Date:	Fri, 16 May 2008 09:40:24 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Huang, Ying" <ying.huang@...el.com>
Cc:	nigel@...el.suspend2.net,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Pavel Machek <pavel@....cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] kexec based hibernation: a prototype of kexec
	multi-stage load

On Thu, May 15, 2008 at 11:27:58PM -0400, Vivek Goyal wrote:
> On Fri, May 16, 2008 at 10:56:15AM +0800, Huang, Ying wrote:
> > On Thu, 2008-05-15 at 19:25 -0700, Eric W. Biederman wrote:
> > > "Huang, Ying" <ying.huang@...el.com> writes:
> > > 
> > > > On Thu, 2008-05-15 at 11:39 -0700, Eric W. Biederman wrote:
> > > > [...]
> > > >> 2) After we figure out our address read the stack pointer from
> > > >>    a fixed location and simply set it.  (This is my preference)
> > > >
> > > > Just for confirmation (My English is poor).
> > > >
> > > > Do you mean that kernel A just read the stack top as re-entry point,
> > > > regardless of whether it is return address or argument 1?
> > > 
> > > What I was thinking was:
> > > 
> > > In kernel A()
> > > 
> > > relocate_new_kernel:
> > > 
> > >         ...
> > > 
> > >         call	*%eax
> > > 
> > > kexec_jump_back_entry:
> > >         /* This code should be PIC so figure out where we are */
> > >         call	1f
> > > 1:
> > >         popl	%edi
> > >         subl	$(1b - relocate_kernel), %edi
> > > 
> > >         /* Setup a safe stack */
> > >         leal    PAGE_SIZE(%edi), %esp
> > >         ...
> > > 
> > > 
> > > Then in purgatory we can read the address of kexec_jump_back_entry
> > > by examining 0(%esp) and export it in whatever fashion is sane.
> > > 
> > > However we reach kexec_jump_back_entry we should be fine.
> > 
> 
> Huang is making use of purgatory only for booting kernel B for the first
> time. Once the kernel B is booted, all the trasitions (A-->B and B<--A)
> happen without using purgatory. Just keep on jumping back and forth
> to "kexec_jump_back_entry".
> 
> Probably not using purgatory for later transitions is justified as long as
> kernel code is simple and small. Otherwise we will shall have to teach
> purgatory also of special case of resuming kernel B or booting kernel B.
> 
> > I think it is reasonable to enable jumping back and forth more than one
> > time. So the following should be possible:
> > 
> > 1. Jump from A to B (actually jump to purgatory, trigger the boot of B)
> > 2. Jump from B to A
> > 3. Jump from A to B again (jump to the kexec_jump_back_entry of B)
> > 4. Jump from B to A
> > ...
> > 
> > So it should be possible to get the re-entry point of kernel B in
> > kexec_jump_back_entry of kernel A too. So I think in
> > kexec_jump_back_entry, the caller's stack should be checked to get
> > re-entry point of peer. And the stack state is different depend on where
> > come from, from relocate_new_kernel() or return.
> > 
> 
> 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
> 

Thinking more about it, probably we don't have to separate out preserve
context and normal kexec path. Both can transition to purgatory using
call %edx. Coloring the stack should not harm in normal kexec.

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