[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [XEN-IOMMU] Proposal of DMA protection/isolation support
Grant mappings will only be triggered for I/O to/from foreign domains. I'm not really convinced that protecting a driver domain's own memory against errant DMAs is that important anyway. Firstly, there are many other ways that a buggy driver can screw its domain, other than errant DMA. Secondly, any driver that haflway works will request a DMA mapping from the OS before it initiates any DMA (otherwise the driver would *never* work) and that would probably be the point at which the OS would set up the iommu mapping. That's the problem -- the OS will be trusting the driver to tell it when a mapping should be set up, and that request will usually be co-located in the driver code with the actual DMA initiation. So if the driver is issuing errant DMAs, the OS is rather likely to let them happen! -- Keir On 10/1/08 16:52, "Wei Wang2" <wei.wang2@xxxxxxx> wrote: > 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |