From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: QEMU bumping memory bug analysis Date: Mon, 08 Jun 2015 14:33:33 +0100 Message-ID: <5575B5CD0200007800082256@mail.emea.novell.com> References: <20150605164354.GK29102@zion.uk.xensource.com> <20150605181014.GM29102@zion.uk.xensource.com> <55758742.5060602@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Wei Liu , Ian Campbell , George Dunlap , Andrew Cooper , IanJackson , dslutz@verizon.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> On 08.06.15 at 15:01, wrote: > On Mon, 8 Jun 2015, Andrew Cooper wrote: >> At the moment, set_max_mem is the only method the toolstack has of >> putting a hard upper bound on a domains memory usage (along with a few >> others like the shadow mem size, and PoD cache.) >> >> In a disaggregated case, no deprivileged entity should be able to play >> with this limit. Being able to do so renders the security moot, as a >> compromised stubdom can force a host OOM. > > You have a good point but I wouldn't say that it renders the security > moot, as one needs to break into the stubdom first, and then it still > only gets as far as OOMing the host, not compromising other people's > data. OOMing the host is quite likely to compromise other people's (i.e. VM's) data, due to Xen having to fail any request to it that involves memory allocation. I'm sure there are code paths here that end in domain_crash(). Jan