linux-kernel - Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid

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: <4A2FE9E1.3020705@zytor.com>
Date:	Wed, 10 Jun 2009 10:14:09 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jaswinder Singh Rajput <jaswinder@...nel.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] x86: cpu/proc.c adding extended_cpuid_level for
 /proc/cpuinfo

>>>>
>>> The more I'm thinking about this I think it was a mistake to put cpuid
>>> level: there in the first place, too.  My opinion is increasingly to
>>> leave this to x86info or other user-space tools.
>>>
>> cpuid level is as important as cpu family, model and stepping.
>>
>> For Intel, in some cases cpuid level is more important then cpu family,
>> model and stepping. Like you cannot tell by looking at cpu family, model
>> and stepping which model is new and which is old like 05_01 or 06_1A or
>> 0F_03H ?
>>
>> But by looking at cpuid level and extended cpuid level you can tell
>> which is new and which is old and which supports more features.
>>
>> So cpuid level and extended cpuid level is better scale than cpu family,
>> model and stepping. So I think hiding this valuable information is a
>> crime.
> 
> cpuid level and extended cpuid level tells the information about Intel
> processor model.  Do you still think it is useless and should not be present
> in /proc/cpuinfo .
> 

I think it's pointless, because if you're doing this kind of stuff you
might as well talk to CPUID directly.  We have a CPUID interface
already.  The kernel isn't meant to replicate x86info or any of those
tools -- it really can't, and at that point why stop at x86info... we
could replicate arbitrary applications at that point.

As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
internally, nevermind display them.

I'm not really all that doctrinal about this, but I'd like to get a
decent answer to the question "where does it stop, *and why*".  It's a
slippery slope, and without a target, it goes on forever.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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