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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200706011407.51779.jbarnes@virtuousgeek.org>
Date:	Fri, 1 Jun 2007 14:07:51 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Justin Piszcz <jpiszcz@...idpixels.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

On Friday, June 1, 2007 2:14:17 Andi Kleen wrote:
> Jesse Barnes <jbarnes@...tuousgeek.org> writes:
> > (or we get proper PAT support, which I think would make this problem
> > go away as well).
>
> No it won't. If the basic MTRRs for memory are wrong just having PAT
> support in drivers (which already exist in a limited form already, just for
> UC only) won't change anything.

No obviously just using PAT for drivers wouldn't help, I was thinking more of 
having one PAT type be WB memory, and using it by default for most PTEs 
covering normal memory.  If that's not possible, then it seems sensible to 
try to fix this MTRR problem in a better way, either with something like the 
patch I posted earlier or a more advanced MTRR remapper that runs at early 
boot.  Depending on platform requirements though, that could get complicated 
pretty fast...

Jesse

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ