linux-kernel - Re: [PATCH 2.6.24] x86: add sysfs interface for cpuid module

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: <47A014AF.5040605@zytor.com>
Date:	Tue, 29 Jan 2008 22:09:51 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	yi.y.yang@...el.com
CC:	tglx@...utronix.de, mingo@...hat.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 2.6.24] x86: add sysfs interface for cpuid module

Yi Yang wrote:
>>
>> It's broken, because it doesn't take into account the fact that Intel 
>> broke CPUID level 4 and made it "repeating" (neither did the cpuid char 
>> device, because it predated the Intel braindamage; I've had a patch for 
>> it privately for a while, but didn't push it upstream because paravirt 
>> broke it royally and I wanted the situation to settle down.)
>>
>> It's broken, because the algorithm used to determine valid CPUID levels 
>> is incorrect; it fails to recognize any CPUID levels other than the main 
>> Intel and AMD ones, e.g. the Transmeta 0x8086xxxx (and sometimes more) 
>> and VIA 0xc000xxxx levels.
> Thank you for pointing out these issues, i think we can let users input
> any cpuid level and output the corresponding cpuid, in this way we can
> avoid to consider cpu differences and left this to userspace. We can
> also consider all the x86 platforms to do cpuid for every one.
> 
>> It's broken, because it is better for the userspace extractor to have 
>> this logic than to stuff it into the kernel, where it sits hogging 
>> unswappable memory at all times.
> It seems not to be very appropriate to let user space consider hardware
> details. /proc/cpuinfo should be an example to justify this.

/proc/cpuinfo represents what the kernel needs to know, so it reflects 
the kernel's interpretation of CPUID.  There is no reason to interpret 
things in the kernel that the kernel doesn't need.

> Is there any user application using /dev/cpu/*/cpuid? if no, i think it
> is feasible to provide an interface in the kernel.

Yes.  It's called x86info, I believe.

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