linux-kernel - Re: [PATCH] x86: trim ram need to check if mtrr is there v3

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, 25 Jan 2008 15:21:50 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <Yinghai.Lu@....COM>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: trim ram need to check if mtrr is there v3

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

> -static __init int amd_special_default_mtrr(unsigned long end_pfn)
> +static __init int amd_special_default_mtrr(void)
>  {
>  	u32 l, h;
>  
> -	/* Doesn't apply to memory < 4GB */
> -	if (end_pfn <= (0xffffffff >> PAGE_SHIFT))
> -		return 0;
>  	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>  		return 0;

The logic we ideally would like to have is something like this:

find _any_ RAM that is not mapped via any MTRRs (be that special MTRR 
extensions like Tom2) and clear that from the e820 maps.

not just 'end of RAM'.

And in that sense the amd_special_default_mtrr() check is wrong, because 
it just checks that Tom2 is set and then does no other checking. And the 
original MTRR check is wrong too because it just finds the highest 
cacheable MTRR-covered address and compares that to the kernel-known end 
of RAM.

what we should probably do instead is to have a filter function:

   new_end = trim_range_to_mtrr_cached(start, end);

and then we could iterate through every e820 map entry that is marked as 
usable RAM, and send it through this filter. If the filter returns the 
same value that got passed in, we keep the e820 entry unchanged. If the 
filter returns a new "end" value, we use that in the e820 map.

that way, the current Tom2 hack is just a natural extension to the 
filter function: it would (on AMD CPUs) recognize (within 
trim_range_to_mtrr_cached filter) that all memory addresses above 4GB 
are marked as cacheable via Tom2.

Or something like this. Hm?

	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/