linux-kernel - Re: [PATCH] x86, aperture: Check for GART before accessing GART registers

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, 2 Apr 2015 10:54:05 -0500
From:	Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	<tglx@...utronix.de>, <mingo@...hat.com>, <hpa@...or.com>,
	<x86@...nel.org>, <bp@...e.de>, <bhelgaas@...gle.com>,
	<linux-kernel@...r.kernel.org>, <Suravee.Suthikulpanit@....com>,
	<joro@...tes.org>
Subject: Re: [PATCH] x86, aperture: Check for GART before accessing GART registers

On 4/2/2015 5:01 AM, Ingo Molnar wrote:
> * Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com> wrote:
>
>> GART registers are not present in newer processors (Fam15h, Model 10h
>> and later). So, avoid accesses to GART registers in PCI config
>> space by returning early in early_gart_iommu_check() and
>> gart_iommu_hole_init() if GART is not available.
> In what fashion did this problem manifest itself on real systems?
>
>

This code doesn't break on existing processors.
There are some other side effects though..

We get "AGP:" messages on kernel logs like this-
[    0.000000] AGP: Node 0: aperture [bus addr 0x00000000-0x01ffffff] (32MB)
[    0.000000] AGP: Your BIOS doesn't leave a aperture memory hole
[    0.000000] AGP: Please enable the IOMMU option in the BIOS setup
[    0.000000] AGP: This costs you 64MB of RAM
[    0.000000] AGP: Mapping aperture over RAM [mem 
0xd4000000-0xd7ffffff] (65536KB)

These are just noise on processors which have no GART.
We can avoid calling allocate_aperture() and would not have to 
memblock_reserve() 64MB of RAM.
Also, we can avoid having to loop through all PCI buses, devices (twice) 
searching for AGP bridge if we bail out early.

For future processors though, we can't say how these registers will be 
implemented.
If we have to provide PCI IDs for them in amd_nb_misc_ids[] and this 
code ends up reading/writing something else then that'd be another problem.

Thanks,
-Aravind.
--
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/