linux-kernel - Re: [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Jan 2012 20:44:29 +0100
From:	Joerg Roedel <joro@...tes.org>
To:	Scott Wood <scottwood@...escale.com>
Cc:	Joerg Roedel <joerg.roedel@....com>,
	Sethi Varun-B16395 <B16395@...escale.com>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Tony Lindgren <tony@...mide.com>,
	Hiroshi DOYU <Hiroshi.DOYU@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Wood Scott-B07421 <B07421@...escale.com>,
	David Brown <davidb@...eaurora.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute

On Thu, Jan 26, 2012 at 01:00:37PM -0600, Scott Wood wrote:
> On 01/26/2012 12:51 PM, Joerg Roedel wrote:
> > Because this is a flag that makes sense for all IOMMU. Every IOMMU
> > either allows DMA outside its aperture or it doesn't.
> > 
> > Another reason why it must be in the generic struct is the intended
> > generic dma-ops layer on-top. This code can decide on this flag wheter a
> > address needs to be remapped at all.
> 
> So the DMA API would just read this, not write it?

The whole geometry thing is only implemented on the read side. There is
no implementation in domain_set_attr for it. So the geometry
information is read-only by default.

> Still no reason why it couldn't be a separate attribute.  Then if you
> get a failure trying to write it, it's more obvious why.

This would mean iommu specific hacks, which are not necessary in this
case.

> > Setting this flag wrong does not create unintended identity mappings.
> 
> Failing to set it means that DMA can go through that is not limited to
> explicitly created mappings.  In some contexts (e.g. vfio) this is a
> security hole.

No, when the hardware does not allow this, then software can't enforce
it. Again, the whole geometry attribute is only for iommu drivers to
export what the hardware can do. It is not for software to configure the
iommu driver.

> > But I don't understand what you mean by 'restrictions on possible values'. The
> > geometry attribute is filled by the IOMMU driver dependent on the
> > hardware capabilities. There are no limits from the iommu-code side.
> 
> How does the user of the iommu API discover the hardware capabilities?

Which hardware capabilities besides the geometry do you mean?


	Joerg

--
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/