linux-kernel - Re: [PATCH]: Compress hibernation image with LZO (in-kernel)

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]

Message-Id: <20100802101058.d4f1c7b6.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Mon, 2 Aug 2010 10:10:58 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Bojan Smojver <bojan@...ursive.com>
Cc:	Nigel Cunningham <nigel@...onice.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH]: Compress hibernation image with LZO (in-kernel)

On Mon, 02 Aug 2010 10:54:13 +1000
Bojan Smojver <bojan@...ursive.com> wrote:

> On Mon, 2010-08-02 at 09:17 +0900, KAMEZAWA Hiroyuki wrote:
> > Now, vmallc() is used here. Then, following will happen.
> > 
> > 1. vmalloc()
> >    -> vmalloc adds vmap objects and set page table entries.
> > 
> > 2. saving image
> >    -> At taking snapshot of memory to the disk, above vmalloc() area
> > is
> >       saved to disk as it is.
> > ...
> > 3. At restore
> >    Because you dont't remember which vmalloc() area was used for
> > creating
> >    snapshot, you can't free it at swsusp_free().
> > 
> > memory leak ? 
> 
> To be honest, I'm not sure.
> 
> However, I thought that by the time save_image() is called, snapshot has
> already been taken, no?
> ------------------
>         error = hibernation_snapshot(hibernation_mode == HIBERNATION_PLATFORM);
>         if (error)
>                 goto Thaw;
> 
>         if (in_suspend) {
>                 unsigned int flags = 0;
> 
>                 if (hibernation_mode == HIBERNATION_PLATFORM)
>                         flags |= SF_PLATFORM_MODE;
>                 pr_debug("PM: writing image.\n");
>                 error = swsusp_write(flags);  <--- this calls save_image()
> ------------------
> 
> So, me thinks that these allocations will not be in the snapshot image.
> 
I'm a very newbie to snapshot ...(I'm now studying it because I got a report
that my patch corrupts it.) So, don't trust my words.

Looking into swsusp_write().
==
swsusp_write()
	-> save_image()
		-> 
		while () {
			snapshot_read_next()
			swap_write_page()
		}
==
This routine writes a buffer which is gotten by snapshot_read_next() to the disk.

Then, what snapshot_read_next() pass is.
==
        } else {
                struct page *page;

                page = pfn_to_page(memory_bm_next_pfn(&copy_bm));
                if (PageHighMem(page)) {
                        /* Highmem pages are copied to the buffer,
                         * because we can't return with a kmapped
                         * highmem page (we may not be called again).
                         */
                        void *kaddr;

                        kaddr = kmap_atomic(page, KM_USER0);
                        memcpy(buffer, kaddr, PAGE_SIZE);
                        kunmap_atomic(kaddr, KM_USER0);
                        handle->buffer = buffer;
                } else {
                        handle->buffer = page_address(page);
                }
        }
==
The physical memory address of a page to be saved.

So, I thought "system memory image" itself is not a snapshot but it's changing
while it runs. Why swsusp can avoid memory leak is that it records which
pages should be freed after resume in the bitmap, which will be saved to
image header(?) And, even if this snapshot saves the image of buddy-allocator,
the save routine itself uses a fixed buffer which can be freed after restore.

Thanks,
-Kame












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