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, 7 May 2009 13:26:01 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	airlied@...ux.ie, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org, mingo@...hat.com,
	dwmw2@...radead.org
Subject: Re: IOMMU and graphics cards


* FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:

> On Thu, 7 May 2009 13:01:35 +0200
> Ingo Molnar <mingo@...e.hu> wrote:
> 
> > 
> > * FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:
> > 
> > > > The proprietary drivers make problems so far. For the ATI one I 
> > > > am in contact with the developers to try to fix it. But I can't 
> > > > do anything about the other proprietary driver I am aware of :-(
> > > 
> > > I don't know anything about the graphic drivers but are there any 
> > > other proprietary drivers except for ATI and AMD? Fixing only two 
> > > drivers to make the majority happy?
> > 
> > ATI ~== AMD these days. The problem is Nvidia cards stuck into AMD 
> > systems.
> 
> Oops, I meant ATI and Nvidia.
> 
> 
> > I guess refusing those DMA accesses (and printing something 
> > meaningful and relentlessly honest so that the user knows where the 
> > problem comes from) is the proper solution.
> 
> Refusing DMA means that we will break these broken drivers. That's 
> what David and I like. Yeah, telling users explicitly who is to 
> blame for the problem is even better.

If it means a non-working Xorg, then there might be nothing on the 
screen to report - just a seemingly hung box and people will blame 
the kernel. It might be better to just turn off all things IOMMU at 
that point, but still allow things to continue.

... which might break good drivers that relied on the IOMMU sorting 
out 32-bit DMA space limitations.

So it would be nice to make the failure mode somehow nicer. I.e. 
test how this affects the nvidia driver. Is there something on the 
screen to see? Could we print an URL to the Noveau driver perhaps 
too?

A bad solution in general is to crash/hang a significant proportion 
of Linux boxes. That is a foot-in-own-mouth masochistic excercise 
mostly, it creates a stigma for the IOMMU code, not for nvidia. So 
the failure mode has to be well thought out.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ