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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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-security-features)
can give you a graphical idea of what we're' talking about.

 -George

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