linux-kernel - Re: 2.6.26, PAT and AMD family 6

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:	Wed, 07 May 2008 15:57:52 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Rene Herman <rene.herman@...access.nl>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Adrian Bunk <bunk@...nel.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	Pavel Machek <pavel@...e.cz>
Subject: Re: 2.6.26, PAT and AMD family 6

Rene Herman wrote:
> On 07-05-08 22:52, Thomas Gleixner wrote:
> 
>>> And why do we need this clear_cpu_cap(c, X86_FEATURE_PAT) and then 
>>> manual setting of X86_FEATURE_PAT at all?
>>
>> The reason is to make cpu_has_pat a useful check and to avoid checking
>> cpu vendors, families and models inside of the PAT code. That's a good
>> thing actually, because the PAT code only cares about that cpu_has_pat
>> flag.
>>
>> Clearing it in the cpuinfo is just a cosmetic side effect which does
>> no harm at all.
> 
> Oh yes, it does. It makes people unaware that their CPUs _should_ be
> supporting PAT. The thing's not called /proc/kernelinfo for a reason.
> 

Okay, that is utter nonsense.  /proc/cpuinfo has always been, and will 
always be, the CPU *AS THE KERNEL SEES IT*.  If you want something else, 
use x86info(1).

> And would yelling at people how shuffle in code without (publicly at
> least) addressing one of your fellow arch maintainers objections and
> Pavel's review comments about code duplication without a single line
> of explanation/changelog do?

We did discuss this (over IRC, I'm afraid), and came to the conclusion 
that it's too risky to do the proper thing (blacklist) straight out the 
gate.  Consider it a staged implementation.  The reason for this is that 
some of the earlier chips have downright frightening errata w.r.t. PAT. 
  *At this point*, we'd have no reasonable way to filter those bug 
reports from the issues with the software itself.

So, one step at a time.  PAT is massively overdue in Linux, so it's no 
wonder you're anxious about it, but we need a modicum of caution here.

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