linux-kernel - Re: [RFC v4][PATCH 4/9] Memory management (dump)

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:	Wed, 10 Sep 2008 09:55:28 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Oren Laadan <orenl@...columbia.edu>
Cc:	containers@...ts.linux-foundation.org, jeremy@...p.org,
	linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: [RFC v4][PATCH 4/9] Memory management (dump)

On Tue, 2008-09-09 at 03:42 -0400, Oren Laadan wrote:
> +       while (addr < end) {
> +               struct page *page;
> +
> +               /*
> +                * simplified version of get_user_pages(): already have vma,
> +                * only need FOLL_TOUCH, and (for now) ignore fault stats.
> +                *
> +                * FIXME: consolidate with get_user_pages()
> +                */
> +
> +               cond_resched();
> +               while (!(page = follow_page(vma, addr, FOLL_TOUCH))) {
> +                       ret = handle_mm_fault(vma->vm_mm, vma, addr, 0);
> +                       if (ret & VM_FAULT_ERROR) {
> +                               if (ret & VM_FAULT_OOM)
> +                                       ret = -ENOMEM;
> +                               else if (ret & VM_FAULT_SIGBUS)
> +                                       ret = -EFAULT;
> +                               else
> +                                       BUG();
> +                               break;
> +                       }
> +                       cond_resched();
> +                       ret = 0;
> +               }

get_user_pages() is really the wrong thing to use here.  It makes pages
*present* so that we can do things like hand them off to a driver.  For
checkpointing, we really don't care about that.  It's a waste of time,
for instance to perform faults to fill the mappings up with zero pages
and page tables.  Just think of what will happen the first time we touch
a very large, very sparse anonymous area.  We'll probably kill the
system just allocating page tables.  Take a look at the comment in
follow_page().  This is a similar operation to core dumping, and we need
to be careful.

This might be fine for a proof of concept, but it needs to be thought
out much more thoroughly before getting merged.  I guess I'm
volunteering to go do that.

-- Dave

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