Re: One question about the hypercall to translate gfn to mfn.

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2015-01-06 at 08:42 +0000, Tian, Kevin wrote:
> > From: George Dunlap
> > Sent: Monday, January 05, 2015 11:50 PM
> > 
> > On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin <kevin.tian@intel.com> wrote:
> > >> We're not there in the current design, purely because XenGT has to be
> > >> in dom0 (so it can trivially DoS Xen by rebooting the host).
> > >
> > > Can we really decouple dom0 from DoS Xen? I know there's on-going effort
> > > like PVH Dom0, however there are lots of trickiness in Dom0 which can
> > > put the platform into a bad state. One example is ACPI. All the platform
> > > details are encapsulated in AML language, and only dom0 knows how to
> > > handle ACPI events. Unless Xen has another parser to guard all possible
> > > resources which might be touched thru ACPI, a tampered dom0 has many
> > > way to break out. But that'd be very challenging and complex.
> > >
> > > If we can't containerize Dom0's behavior completely, I would think dom0
> > > and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> > > make things worse.
> > 
> > The question here is, "If a malicious guest can manage to break into
> > XenGT, what can they do?"
> > 
> > If XenGT is running in dom0, then the answer is, "At very least, they
> > can DoS the host because dom0 is allowed to reboot; they can probably
> > do lots of other nasty things as well."
> > 
> > If XenGT is running in its own domain, and can only add IOMMU entries
> > for MFNs belonging to XenGT-only VMs, then the answer is, "They can
> > access other XenGT-enabled VMs, but they cannot shut down the host or
> > access non-XenGT VMs."
> > 
> > Slides 8-11 of a presentation I gave
> > (http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-s
> > ecurity-features)
> > can give you a graphical idea of what we're' talking about.
> > 
> 
> I agree we need to make XenGT more isolated following on-going trend from
> previous discussion, but regarding to whether Dom0/Xen are in the same security
> domain, I don't see my statement is changed w/ above attempts which just try to 
> move privileged Xen stuff away from dom0, but all existing Linux vulnerabilities 
> allow a tampered Dom0 do many evil things with root permission or even tampered 
> kernel to DoS Xen (e.g. w/ ACPI). PVH dom0 can help performance... but itself alone 
> doesn't change the fact that Dom0/Xen are actually in the same security domain. :-)

Which is a good reason why one would want to remove as much potentially
vulnerable code from dom0 as possible, and then deny it the
corresponding permissions via XSM too.

I also find the argument "dom0 can do some bad things so we should let
it be able to do all bad things" rather specious.

Ian.