lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 29 Oct 2015 18:42:10 +0000 From: Robin Murphy <robin.murphy@....com> To: Will Deacon <will.deacon@....com>, Alex Williamson <alex.williamson@...hat.com> Cc: iommu <iommu@...ts.linux-foundation.org>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, "eric.auger" <eric.auger@...aro.org> Subject: Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass On 29/10/15 18:28, Will Deacon wrote: > On Tue, Oct 27, 2015 at 10:00:11AM -0600, Alex Williamson wrote: >> On Tue, 2015-10-27 at 15:40 +0000, Will Deacon wrote: >>> On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote: >>>> Would it be possible to add iommu_domain_geometry support to arm-smmu.c? >>>> In addition to this test to verify that DMA cannot bypass the IOMMU, I'd >>>> eventually like to pass the aperture information out through the VFIO >>>> API. Thanks, >>> >>> The slight snag here is that we don't know which SMMU in the system the >>> domain is attached to at the point when the geometry is queried, so I >>> can't give you an upper bound on the aperture. For example, if there is >>> an SMMU with a 32-bit input address and another with a 48-bit input >>> address. >>> >>> We could play the same horrible games that we do with the pgsize bitmap, >>> and truncate some global aperture everytime we probe an SMMU device, but >>> I'd really like to have fewer hacks like that if possible. The root of >>> the problem is still that domains are allocated for a bus, rather than >>> an IOMMU instance. >> >> Yes, Intel VT-d has this issue as well. In theory we can have >> heterogeneous IOMMU hardware units (DRHDs) in a system and the upper >> bound of the geometry could be diminished if we add a less capable DRHD >> into the domain. I suspect this is more a theoretical problem than a >> practical one though as we're typically mixing similar DRHDs and I think >> we're still capable of 39-bit addressing in the least capable version >> per the spec. >> >> In any case, I really want to start testing geometry.force_aperture, >> even if we're not yet comfortable to expose the IOMMU limits to the >> user. The vfio type1 shouldn't be enabled at all for underlying >> hardware that allows DMA bypass. Thanks, > > Ok, I'll put it on my list of things to look at under the assumption that > the actual aperture limits don't need to be accurate as long as DMA to > an arbitrary unmapped address always faults. I'm pretty sure we'd only ever set the aperture to the full input address range anyway (since we're not a GART-type thing), in which case we should only need to worry about unmatched streams that don't hit in a domain at all. Doesn't the disable_bypass option already cover that? (FWIW I hacked it up for v2 a while back, too[0]). Robin. [0]:http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=23a251189fa3330b799a837bd8eb1023aa2dcea4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists