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]
Message-ID: <484FCC09.7020606@keyaccess.nl>
Date:	Wed, 11 Jun 2008 14:58:49 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Andreas Herrmann <andreas.herrmann3@....com>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	qt@...erich.amd.com
Subject: Re: [PATCH 2/5] x86: PAT: fix ambiguous paranoia check in	pat_init()

On 11-06-08 11:41, Andreas Herrmann wrote:

> As I had no Transmeta or Centaur CPU at hand I just cleared the PAT
> flag in the CPU identification code to simulate the case that all CPUs
> of a Vendor are whitelisted (even those w/o PAT support).  The first
> time pat_init() is entered you get
> 
>   PAT enabled, but CPU feature cleared 
>     (=> which is wrong as no flag was cleared)

Again, you are misreading this. Please just replace the message mentally 
by "PAT enabled, but CPU claims to not support PAT". "cleared" here does 
not signify that we ourselves cleared anything, just that flag IS clear 
(unset). Yes, maybe the wording could be better but it's not wrong.

>   x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>     (=> which is wrong as PAT shouldn't be enabled on such CPUs)

Again not wrong, or at least by design. Thomas Gleixner did it this way 
and with that "paranoia check" explicitly bombing out only for SMP this 
wouldn't have been by accident. He no doubt knows why he did so (and 
he's in CC so if we're real lucky we might also now...)

> IMHO the current state is:
> 
> We can whitelist all Transmeta, Centaur and AMD CPUs (no errata wrt
> PAT are known).  So the assumption is that for those CPUs PAT works if
> advertised.
> 
> Then we have Intel for which all family 0xf CPUs, and family 6 CPUs
> starting with model 15 are whitelisted. AFAIK there are other Intel
> CPUs that advertise PAT support.

Definitely. Even my P2 (family 6, model 5) does. The whitelist was 
discussed to be a temporary measure in an attempt to for now not muddy 
testing of the feature with reports from CPUs in which the feature 
designers weren't particularly interested. It should be turned into a 
blacklist at a relatively nearby point after which also no whitelisting 
command line switches are needed anymore.

I have myself been applying a patch to whitelist all of AMD family 6 but 
  with things just temporary this is no big deal...

Rene.
--
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