From: Wei Liu <wei.liu2@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
dslutz@verizon.com, xen-devel@lists.xen.org
Subject: Re: QEMU bumping memory bug analysis
Date: Mon, 8 Jun 2015 14:32:20 +0100 [thread overview]
Message-ID: <20150608133220.GE29102@zion.uk.xensource.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1506081425120.19838@kaball.uk.xensource.com>
On Mon, Jun 08, 2015 at 02:27:11PM +0100, Stefano Stabellini wrote:
> On Mon, 8 Jun 2015, Wei Liu wrote:
> > On Mon, Jun 08, 2015 at 12:39:52PM +0100, Stefano Stabellini wrote:
> > [...]
> > > > > > 3. Add a libxl layer that wraps necessary information, take over
> > > > > > Andrew's work on libxl migration v2. Having a libxl layer that's not
> > > > > > part of migration v2 is a waste of effort.
> > > > > >
> > > > > > There are several obstacles for libxl migration v2 at the moment. Libxl
> > > > > > layer in migration v2 still has unresolved issues. It has
> > > > > > inter-dependency with Remus / COLO.
> > > > > >
> > > > > > Most importantly it doesn't inherently solve the problem. It still
> > > > > > requires the current libxl JSON blob to contain information about max
> > > > > > pages (or information used to derive max pages).
> > > > > >
> > > > > > Andrew, correct me if I'm wrong.
> > > > > >
> > > > > > 4. Add a none user configurable field in current libxl JSON structure to
> > > > > > record max pages information.
> > > > > >
> > > > > > This is not desirable. All fields in libxl JSON should be user
> > > > > > configurable.
> > > > > >
> > > > > > 5. Add a user configurable field in current libxl JSON structure to
> > > > > > record how much more memory this domain needs. Admin is required to
> > > > > > fill in that value manually. In the mean time we revert the change in
> > > > > > QEMU and declare QEMU with that change buggy.
> > > > >
> > > > > QEMU 2.3.0 was released with that change in it, so it is not quite
> > > > > possible to revert it. Also I think it is the right change for QEMU.
> > > > >
> > > >
> > > > It has security implications. Here is my reply copied from my mail to
> > > > Ian:
> > > >
> > > > I'm considering removing xc_domain_setmaxmem needs regardless of this
> > > > bug because that's going to cause problem in QEMU upstream stubdom with
> > > > strict XSM policy and deprivileged QEMU (may not have privilege to call
> > > > setmaxmem).
> > >
> > > QEMU running in the stubdom should be able to set the maxmem for its
> > > target domain, but not for the others.
> > >
> >
> > Right, but this is still not safe. I will explain below.
> >
> > >
> > > > The security implication as it is now is big enough. One malicious guest
> > > > that controls QEMU has a vector to DoS hypervisor by setting its own
> > > > max_pages to -1;
> > >
> > > Is that an issue in the implementation of XEN_DOMCTL_max_mem on the Xen
> > > side? Could you please give me a bit more info on this security issue?
> > >
> >
> > Consider now we have a malicious guest. It has gained control of QEMU.
> > It then calls xc_domain_setmaxmem to set it's own max_pages inside
> > hypervisor to be -1 and start calling populate_physmap inside the guest
> > kernel. This is going to make hypervisor OOM.
> >
> > XEN_DOMCTL_max_mem only sets the limit of domain at the moment. I don't
> > think there is sensible way of distinguishing a valid setmaxmem call
> > from a malicious setmaxmem call from QEMU. It's untrusted code base
> > after all.
>
> Valid maxmem happens before device-model/$DOMID/state is set to running.
>
But Xen wouldn't know about that. It couldn't read xenstore. Also
device-mode/$domid/state is writable by QEMU so we can't trust the
content as indicator either.
Wei.
next prev parent reply other threads:[~2015-06-08 13:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 16:43 QEMU bumping memory bug analysis Wei Liu
2015-06-05 16:58 ` Ian Campbell
2015-06-05 17:13 ` Stefano Stabellini
2015-06-05 19:06 ` Wei Liu
2015-06-05 17:17 ` Andrew Cooper
2015-06-05 17:39 ` Wei Liu
2015-06-05 17:10 ` Stefano Stabellini
2015-06-05 18:10 ` Wei Liu
2015-06-08 11:39 ` Stefano Stabellini
2015-06-08 12:14 ` Andrew Cooper
2015-06-08 13:01 ` Stefano Stabellini
2015-06-08 13:33 ` Jan Beulich
2015-06-08 13:10 ` Wei Liu
2015-06-08 13:27 ` Stefano Stabellini
2015-06-08 13:32 ` Wei Liu [this message]
2015-06-08 13:38 ` Stefano Stabellini
2015-06-08 13:44 ` Andrew Cooper
2015-06-08 13:45 ` Stefano Stabellini
2015-06-05 18:49 ` Ian Campbell
2015-06-08 11:40 ` Stefano Stabellini
2015-06-08 12:11 ` Ian Campbell
2015-06-08 13:22 ` Stefano Stabellini
2015-06-08 13:52 ` Ian Campbell
2015-06-08 14:20 ` George Dunlap
2015-06-08 15:01 ` Don Slutz
2015-06-08 15:37 ` George Dunlap
2015-06-08 16:06 ` Don Slutz
2015-06-09 10:00 ` George Dunlap
2015-06-09 10:17 ` Wei Liu
2015-06-09 10:14 ` Stefano Stabellini
2015-06-09 11:20 ` George Dunlap
2015-06-16 16:44 ` Stefano Stabellini
2015-06-09 12:45 ` Ian Campbell
2015-06-17 13:35 ` Stefano Stabellini
2015-06-08 14:53 ` Konrad Rzeszutek Wilk
2015-06-08 15:20 ` George Dunlap
2015-06-08 15:42 ` Konrad Rzeszutek Wilk
2015-06-08 14:14 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150608133220.GE29102@zion.uk.xensource.com \
--to=wei.liu2@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dslutz@verizon.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.