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, 7 May 2008 17:15:31 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Rene Herman <rene.herman@...access.nl>,
	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>,
	akpm@...ux-foundation.org, Pavel Machek <pavel@...e.cz>
Subject: Re: 2.6.26, PAT and AMD family 6

On Wed, 7 May 2008, H. Peter Anvin wrote:
> > 
> > What a lovely way of syncing reality with your definitions. The kernel
> > _does_ see that my CPU features PAT, it just refuses to use it because
> > it doesn't trust it enough. Vital difference. Maybe not to the kernel,
> > but definitely to me, the user. /proc/cpuinfo is a user interface.
> > 
> 
> No, /proc/cpuinfo is informing the user about the kernel's view of the CPU.
> It has always been the "cooked" view of CPUID, whether or not you like it.

Indeed. If people want to know what the CPU itself reports, they should 
just use the "cpuid" instruction directly. The /proc/cpuinfo file has 
been a window into the kernels notion of what is going on, and disabling 
kernel features have disabled the bits in that file as appropriate (eg 
"clearcpuid=xyzzy" and "mem=nopentium" etc).

Of course, the *common* case is that the two will match 100% in features. 
But the kernel view has some of its very own set of CPU features too.

And it is possible that the "PAT as the kernel sees it" should be a 
*separate* bit from "PAT as the cpu itself reports to support it". We do 
that for quite a lot of the "synthesized" features, eg there is the "TSC" 
feature as the CPU reports it, and then we have the "CONSTANT_TSC" feature 
that is the kernel version of it that says that we have a TSC _and_ it 
runs at a constant rate too (or the "UP" bit, or the "Mfence synchronizes 
RDTSC" bit etc etc).

So it's possible that we should do the same thing for PAT - and allow 
people to see the CPU view _and_ the kernel view as two separate issues. 
In many ways that would be the logical thing to do. Hmm?

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