linux-kernel - Re: MTRR initialization

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, 20 Sep 2007 14:05:28 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Jesse Barnes <jesse.barnes@...el.com>, Howard Chu <hyc@...as.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: MTRR initialization

Andi Kleen wrote:
> Jesse Barnes <jesse.barnes@...el.com> writes:
>   
>> To do this in a nicer way (and be less vulnerable to similar BIOS 
>> funkiness) the kernel really needs full PAT support.  That should allow 
>> WC over WB and WC over UC mappings to occur, at least if I'm 
>> remembering the docs right...
>>     
>
> PAT only really helps for device driver performance optimizations.
> But if the basic WB MTRRs are wrong PAT cannot really salvage it. 
>   

Is there any reason not to set the MTRRs to define the entire memory as 
write back, and use PAT exclusively for setting cacheability?

On my home machine for instance, the BIOS uses all 8 MTRRs leaving none 
for X.  I hacked it by merging a couple of MTRRs but this isn't a 
generic solution.

-- 
error compiling committee.c: too many arguments to function

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