linux-kernel - Re: [PATCH] x86-64: disable the GART early v2

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:	Fri, 11 Jan 2008 09:14:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <Yinghai.Lu@....COM>
Cc:	Andi Kleen <ak@...e.de>, Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>, ebiederm@...ssion.com,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86-64: disable the GART early v2

* Yinghai Lu <Yinghai.Lu@....COM> wrote:

> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -218,6 +218,73 @@ static __u32 __init search_agp_bridge(u32 *order, int *valid_agp)
>  	return 0;
>  }
>  
> +void __init early_gart_iommu_disable(void)
> +{
> +	/*
> +	 * disable it in case it is enabled before, esp for kexec/kdump,
> +	 * previous kernel already enable that. otherwise memset called
> +	 * by allocate_aperture/__alloc_bootmem_nopanic cause restart.
> +	 * or second kernel have different position for GART hole. and new
> +	 * kernel could use hole as RAM that is still used by GART set by
> +	 * first kernel
> +	 */

hm, i'm wondering, instead of modifying the GART, why dont we simply 
_detect_ whatever GART settings we have inherited, and propagate that 
into our e820 maps? I.e. if there's inconsistency, then punch that out 
from the memory maps and just dont use that memory.

that way it would not matter whether the GART settings came from a [old 
or crashing] Linux kernel that has not called gart_iommu_shutdown(), or 
whether it's a BIOS that has set up an aperture hole inconsistent with 
the memory map it passed. (or the memory map we _think_ i tried to pass 
us)

it would also be more robust to only read and do a memory map quirk 
based on that, than actively trying to change the GART so early in the 
bootup. Later on we have to re-enable the GART _anyway_ and have to 
punch a hole for it.

and as a bonus, we would have shored up our defenses against crappy 
BIOSes as well.

	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/