linux-kernel - Re: [PATCH] disable CPU side GART accesses

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:	Tue, 4 Nov 2008 09:55:51 +1000
From:	"Dave Airlie" <airlied@...il.com>
To:	bob.montgomery@...com
Cc:	"Dave Jones" <davej@...hat.com>, "Yinghai Lu" <yinghai@...nel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"vojtech@...e.cz" <vojtech@...e.cz>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"chandru@...ibm.com" <chandru@...ibm.com>,
	"Joerg Roedel" <joerg.roedel@....com>,
	"FUJITA Tomonori" <fujita.tomonori@....ntt.co.jp>,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Pavel Machek" <pavel@....cz>
Subject: Re: [PATCH] disable CPU side GART accesses

On Tue, Nov 4, 2008 at 9:36 AM, Bob Montgomery <bob.montgomery@...com> wrote:
> On Wed, 2008-10-29 at 21:40 +0000, Dave Airlie wrote:
>> On Thu, Oct 30, 2008 at 7:32 AM, Dave Jones <davej@...hat.com> wrote:
>> > On Thu, Oct 30, 2008 at 07:24:34AM +1000, Dave Airlie wrote:
>> >
>> >  > This stops the CPU from using the aperture for most DRI things. I
>> >  > can't confirm this won't regress working systems
>> >  > though. The whole AMD GART thing scares me, esp if some of the host
>> >  > chipsets also have an AGP GART.
>> >
>> > The easy cop-out for those in the past has been 'dont support them'.
>> > It's why we removed some K8 chipset PCI IDs from the via driver for eg.
>> > iirc, if we leave them unprogrammed, they're essentially irrelevant.
>> >
>>
>> I was more going the other way, why use the IOMMU for AGP when it has
>> other tasks to
>> do, and we have a host chipset GART.
>>
>> Granted I've never had an AMD + AGP system to ever care about this.
>
> We're specifically talking about AMD64, and we're not using an IOMMU for
> AGP, we're using the AMD64 implementation of the GART for an IOMMU.
> The (possible) danger is that some old AMD64 system could also (or
> instead) try using the GART for AGP and run into a problem since my
> patch wants to disable CPU side access to the aperture, which is fine
> when we're using it as an IOMMU.
>
> In drivers/gpu/drm/drm_memory.c:agp_remap(), there are these comments
> about the part of the code that deals with "cant_use_aperture":
>
> /*
>  * OK, we're mapping AGP space on a chipset/platform on which
>  * memory accesses by the CPU do not get remapped by the GART.
>  * We fix this by using the kernel's page-table instead (that's
>  * probably faster anyhow...).
>  */
>
> So that's encouraging.  Now the question is this:  Can I just go into
> amd64-agp.c and add ".cant_use_aperture=true" to the agp_bridge_driver
> struct?  Who's brave enough to say that will just work? :-)

I have serious doubts about including such a patch without testing on
a large range of AMD64 systems
with a large range of distro/X servers.

Dave.

>
> static const struct agp_bridge_driver amd_8151_driver = {
> ...
>
> The "cant_use_aperture" paths have possibly
> never been tested on amd64 agp systems, but
> are in use on these systems:
>
> alpha-agp.c:    .cant_use_aperture      = true,
> hp-agp.c:       .cant_use_aperture      = true,
> i460-agp.c:     .cant_use_aperture      = true,
> parisc-agp.c:   .cant_use_aperture      = true,
> sgi-agp.c:      .cant_use_aperture = true,
> uninorth-agp.c: .cant_use_aperture      = true,
> uninorth-agp.c: .cant_use_aperture      = true,
>
> Thanks for any more enlightenment,
> Bob Montgomery
>
>
>
>
>
>
>
>
--
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/