[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] QEMU bumping memory bug analysis



>>> On 08.06.15 at 15:01, <stefano.stabellini@xxxxxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.