On Wed, 2015-10-28 at 07:07 -0700, David Miller wrote: > In the sparc64 case, the 64-bit DMA address space is divided into > IOMMU translated and non-IOMMU translated. > > You just set the high bits differently depending upon what you want. Wait, does that mean a (rogue) device could *always* get full access to physical memory just by setting the high bits appropriately? That mapping is *always* available? > So a device could use both IOMMU translated and bypass accesses at > the same time. While seemingly interesting, I do not recommend we > provide this kind of flexibility in our DMA interfaces. Now I could understand this if the answer to my question above was 'no'. We absolutely want the *security* all the time, and we don't want the device to be able to do stupid stuff. But if the answer was 'yes' then we take the map/unmap performance hit for... *what* benefit? On Intel we have the passthrough as an *option* and I have the same initial reaction — "Hell no, we want the security". But I concede the performance motivation for it, and I'm not *dead* set against permitting it. If I tolerate a per-device request for passthrough mode, that might prevent people from disabling the IOMMU or putting it into passthrough mode *entirely*. So actually, I'm *improving* security... I think it makes sense to allow performance sensitive device drivers to *request* a passthrough mode. The platform can reserve the right to refuse, if either the IOMMU hardware doesn't support that, or we're in a paranoid mode (with iommu=always or something on the command line). -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
