Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: George Dunlap
> Sent: Monday, January 05, 2015 11:50 PM
> 
> On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin <kevin.tian@xxxxxxxxx> 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. 
:-)

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