linux-kernel - Re: IOMMU and graphics cards

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]

Message-Id: <20090507164742V.fujita.tomonori@lab.ntt.co.jp>
Date:	Thu, 7 May 2009 16:47:14 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	joerg.roedel@....com
Cc:	dwmw2@...radead.org, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org, mingo@...hat.com,
	fujita.tomonori@....ntt.co.jp, airlied@...ux.ie
Subject: Re: IOMMU and graphics cards

On Tue, 28 Apr 2009 18:04:48 +0200
Joerg Roedel <joerg.roedel@....com> wrote:

> On Tue, Apr 28, 2009 at 04:28:50PM +0100, David Woodhouse wrote:
> > On Tue, 2009-04-28 at 17:05 +0200, Joerg Roedel wrote:
> > 
> > For that device, yes. The IOMMU still catches errors from _other_
> > devices, of course.
> 
> Yes, it is in effect for other devices. But since its a security feature
> it only makes sense if it covers all devices.

For me, IOMMUs are not about security but accessing all memory space
(there are still lots of devices that are not capable of 64-bit DMA)
but I agree that this workaround is bad.


> > Is the reason you're doing this actually because of broken drivers? Or
> > just because of the performance implications? I've heard both cited as
> > reasons for the 1:1 mapping... and if it's mostly the former, then
> > perhaps the best way for me to help you is to stop enabling the option
> > in Fedora (rawhide, at least), so that the buggy drivers get _fixed_ and
> > you don't get stuck with "it works on Intel, why can't you make it
> > work?" reports?
> 
> Currently some graphics drivers don't work with IOMMU enabled because
> they don't use the DMA-API. The silently assume that device addess ==
> physical address.
> I don't know how it is solved for VT-d but for AMD IOMMU the available
> DMA memory address space is limited per device. This is a problem for
> graphics card drivers because, as developers told me, they may need
> gigabytes of DMA memory. I am currently thinking about ways to fix that
> without enlarging the DMA address space for each device (which would be
> a huge waste of memory).

Do you meant that AMD IOMMU code use the bitmap each device to manage
address space so enlarging the DMA address space wastes memory?


>  But unless this problem isn't solved the
> drivers won't be fixed, I guess.
> I guess the DRM code in the kernel may have the same problem with IOMMU
> enabled?

Looks like the DRM code uses the DMA API.


> > > 	* Implement a kernel command line option to enable/disable the
> > > 	  workaround (what should be default?)
> > > 	* Use the IOMMU-API and write a kernel module which creates a
> > > 	  direct mapped protection domain and assigns the graphics
> > > 	  cards to it (need to be done carefully to not break graphics 
> > > 	  drivers which do everything right and use the DMA-API)
> > > 	* Any other great idea?
> > 
> > I think I also prefer your second option. I don't like having this as a
> > hack in the IOMMU code.
> 
> Ok, so I will implement such a module and send the code around for
> discussion.

Yeah, the kernel boot option or the config option don't make sense
since distributions always need to enable the workaround.

btw, what graphic drivers are broken? No chance to fix them?
--
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/