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 13:00:37 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	Joerg Roedel <joerg.roedel@....com>
CC:	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 01/26/2012 12:51 PM, Joerg Roedel wrote:
> On Thu, Jan 26, 2012 at 12:42:10PM -0600, Scott Wood wrote:
>> On 01/26/2012 12:31 PM, Joerg Roedel wrote:
>>> The force_aperture flag indicated whether DMA is only allowed between
>>> aperture_start and apertuer_end or if DMA is allowed outside of this
>>> range too (unmapped in this case).
>>>
>>> The AMD GART for example would set this flag to false because it does
>>> not enforce DMA to be in the aperture-range.
>>
>> Why is this not an AMD GART specific attribute?  Is there any feature
>> reporting mechanism by which a user would know if that flag is supported?
> 
> 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?

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.

>> If it must be in the generic struct, it would be nice to invert the
>> polarity so that the default (after zeroing) is something that should be
>> more widely supportable, and less likely to create unintended identity
>> mappings.
> 
> 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.

>> How in general are available attributes and restrictions on possible
>> values to be communicated to users of the API?
> 
> The possible attributes can be found in inlude/linux/iommu.h.

I meant possible for the currently running hardware.

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

-Scott

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