linux-kernel - Re: A kexec approach to 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:	Mon, 4 Jun 2007 10:10:41 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Jeremy Maitin-Shepard <jbms@....edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pavel Machek <pavel@....cz>
Subject: Re: A kexec approach to hibernation

On Fri, Jun 01, 2007 at 07:54:30PM -0400, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@...k.pl> writes:
> 
> > On Saturday, 2 June 2007 00:25, Jeremy Maitin-Shepard wrote:
> 
> [snip]
> 
> >> Just before jumping into the new kernel, with interrupts disabled, the
> >> old kernel could either prepare a data structure that specifies what
> >> pages are allocated, or alternatively simply provide a pointer to the
> >> relevant data structure in the old kernel.
> 
> > But for this purpose the old kernel will actually need to do what is currently
> > done in swsusp while the image is being created (the only difference is that
> > we allocate memory in the process, but that's a detail only).
> 
> Okay, but creating a list of pages should be extremely easy.
> Alternatively, with the "save kernel" might be able to read the existing
> data structures directly.
> 

Can't we do it Kdump way? Kdump creates ELF headers and stores these in 
memory. Address of these elf headers is passed to second kernel through
command line parameter. These ELF headers contain the information regarding
what memory areas need to be captured by the second kernel.

Can't we adopt similar raw approach for hibernation? Reserve a memory
area for second kernel (This is not used by first kernel). During hibernation,
load second kernel in reserved memory area which will also determine
what physical memory needs to be saved (possibly reading /proc/iomem) and
create ELF headers and then second kernel can parse these headers and save
the memory. The output file can possibly be and ELF image again so that
restoring back becomes easier.

I am just thinking that do we have to create a list of pages etc? Can't we
just copy the raw memory to disk and restore it back. Information regarding
where a chunk of memory should go back will be provided by the ELF header.

One fall side would be that problem of reserving a memory area constantly
and this memory area is currently reserved at first kernel boot time. Can we
somehow make this reservation dynamic? Something like using hugepage support
so that we can allocate big chunks of contiguous physical memory from user
space (32MB or 64MB) at run time.

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/