On Thu, 2008-01-10 at 15:54 +0000, Keir Fraser wrote:
> Grant table mappings/unmappings are an obvious place where we already trap
> to the hypervisor and could make correspodning changes to iommu mappings?
Can grant mapping cover the situation in which a device only be accessed
by a driver domain other than be shared with any remote domain? In other
word, when a device is only access by a driver domain, does grant table
mapping still happen? If yes, it is the best way to go.
> It depends if we want the iommu to do any more than prevent arbitrary DMA
> access to foreign pages. What's the threat model you are wanting to use the
> iommu to protect against?
I think IOMMU can help to prevent buggy driver from destroying memory content
of both
driver domain itself and foreign domain. Proper IO address which is
requested by device driver should only be provided by some pre-defined
interfaces/hypercalls. Arbitrary dma addresses written to a device by a
buggy driver will not trigger address translations.
-Wei
> -- Keir
>
> On 10/1/08 15:48, "Wei Wang2" <wei.wang2@xxxxxxx> wrote:
>
> > hi list,
> > I am considering adding DMA protection/isolation support for iommu
> > machine: Below are the suggested approaches to be discussed:
> >
> > 1) Para-virtualized IOMMU
> > If it is possible to integrate IOMMU driver into guest kernel, we can
> > just implement a set of para-virtualized interface to forward hardware
> > operations from guest to HV. Guest kernel will allocation IO page table
> > for itself, but IO-PTE updating is verified by HV through hypercall.
> >
> > 2) IOMMU-aware dma layer.
> > Currently, driver domain utilizes swiotlb to get dma_address below 4G,
> > which is an additional overhead to IOMMU machine. For IOMMU machine, we
> > can implement a new dma layer which takes "guest_domain-id",
> > "device_bdf", and "guest_page" information as parameters and returns
> > virtual io address to guest OS. Guest OS only have very limited
> > knowledge/control to IOMMU. In this case, HV will allocate and update IO
> > page table for guest domain.
> >
> > 3) Hooking guest memory changes
> > No guest OS modification is needed in this approach. All we need is to
> > update IO page table when guest physical memory changes triggered by
> > domain initialization, ballooning, and grant reference mapping...
> >
> > Thanks for any comments, ideas, corrections... to this thread.
> >
> > -Wei
> >
> >
> >
> >
> >
> >
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home