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: <20110526181554.GB3572@elte.hu>
Date:	Thu, 26 May 2011 20:15:54 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	James Morris <jmorris@...ei.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kees Cook <kees.cook@...onical.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Will Drewry <wad@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, gnatapov@...hat.com,
	Chris Wright <chrisw@...s-sol.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call
 filtering


* Avi Kivity <avi@...hat.com> wrote:

> On 05/26/2011 02:38 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@...hat.com>  wrote:
> >
> >>  >  The biggest amount of RAM is the guest RAM image - but if that is
> >>  >  mmap(SHARED) and mapped using hugepages then the pte overhead
> >>  >  from a process model is largely mitigated.
> >>
> >>  That doesn't work with memory hotplug.
> >
> > Why not, if we do the sensible thing and restrict the size 
> > granularity and alignment of plugged/unplugged memory regions to 
> > 2MB?
> 
> Once forked, you cannot have new shared anonymous memory, can you?

We can have named shared memory.

Incidentally i suggested this to Pekka just yesterday: i think we 
should consider guest RAM images to be named files on the local 
filesystem (prefixed with the disk image's name or so, for easy 
identification), this will help with debugging and with swapping as 
well. (This way guest RAM wont eat up regular anonymous swap space - 
it will be swapped to the filesystem.)

As a sidenote, live migration might also become possible this way: in 
theory we could freeze a guest to its RAM image - which can then be 
copied (together with the disk image) to another box as files and 
restarted there, with some some hw configuration state dumped to a 
header portion of that RAM image as well. (outside of the RAM area)

Thanks,

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ