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
| ||
|
Date: Fri, 11 Jul 2008 04:32:58 +0400 From: Alexey Dobriyan <adobriyan@...il.com> To: Dave Hansen <dave@...ux.vnet.ibm.com> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, "Serge E. Hallyn" <serue@...ibm.com>, Oren Laadan <orenl@...columbia.edu>, Kirill Korotaev <dev@...allels.com>, containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org, Nadia.Derbey@...l.net, Andrew Morton <akpm@...ux-foundation.org>, nick@...k-andrew.net Subject: Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation with a specified id) On Thu, Jul 10, 2008 at 12:47:32PM -0700, Dave Hansen wrote: > On Thu, 2008-07-10 at 12:21 -0700, Eric W. Biederman wrote: > > > Are we talking about the VMA itself, or the memory backing the VMA? > > > > The memory backing the VMA. We need to store the page protections > > that the memory was mapped with as well now that you point it out. A > > VMA is not user space visible, which is why we can arbitrarily split > > and merge VMAs. > > It is visible with /proc/$pid/{maps,smaps,numamaps?}. That's the only > efficient way I know of from userspace to figure out where userspace's > memory is and if it *is* file backed, and what the permissions are. None of those files exist if PROC_FS is off. > We also can't truly split them arbitrarily because the memory cost of > the VMAs themselves might become too heavy (the remap_file_pages() > problem). > > It gets trickier when things are also private mappings in addition to > being in a file-backed VMA. We *do* need to checkpoint those, but only > the pages to which there was a write. > > There's also the problem of restoring things read-only, but VM_MAYWRITE. > If there's a high level of (non-COW'd) sharing of these anonymous areas, > we may not be able to even restore the set of processes unless we can > replicate the sharing. We might run out of memory if the sharing isn't > replicated. -- 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/
Powered by blists - more mailing lists