[Xen-devel] Re: [XEN-IOMMU] Proposal of DMA protection/isolation support

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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