[RESOLVED] How to get Processor Serial Number

[ovidiucucu]

Well, this question was posted tens times.
I know that acual Intel/AMD CPUs does not support Processor Serial Number.
Next function demonstrates this. Executing CPUID with EAX=1, and then test bit 18 of EDX (Processor Serial Number feature flag - is always '0').

bool CPU::IsCPUSerialSupported()
{
   bool bSupported = false;
   DWORD cpufeat   = 0;
   _asm
   {
      xor    eax, eax
      inc    eax
      CPUID
      mov    cpufeat, edx
   }
   if(0x00040000 & cpufeat) // get bit 18 
   {
      bSupported = true;
   }
   return bSupported;
}

Sorry for mixing C++ with assembly code (I'm not an assemblyguru )
In fact, MY QUESTION IS:
Does enybody know why it is not supported?
Is it not possible for the manufacturer to assure an unique one, or it's a privacy reason, or someting else?
Also, does enybody know if this will be changed in the future?

[Bornish]

Hi Ovidiu!
Interesting subject you're bringing. Don't know too much about so many processors types and manufacturers, so you've made me curious about it.
It seems same as for graphics cards, or in fact, for most of the hardware, ... there're no rules constraining the manufacturers about certain things.
Did search about more info and came across some nice links.
Just in case it might bring you something useful:
http://osdev.berlios.de/cpuid.html
http://www.sandpile.org/ia32/cpuid.htm
http://www.ka9q.net/code/cpuid/
http://grafi.ii.pw.edu.pl/gbm/x86/cpuid.html
http://www.paradicesoftware.com/specs/cpuid/

Best part I've read on this subject was:

Originally Posted by PARADICE Software

Unfortunately, there is a small problem with just calling CPUID to find the CPU information, and that is: If the CPU you are running on does not support CPUID, it will crash (or, as the OS likes to call it, an "Invalid Instruction Exception"). There is a method of "checking" the CPU to see if it supports CPUID, but (of course) the check only works on 486+ class CPUs. Relax, though, because the process (and appropriate source code) to find out as much information as possible from any given CPU type is here, in flow-chart form (this assumes you are using at least a 386, which is a moot point as any compiler you'll find nowadays will require at least a 386 processor)

Best of luck,

[ovidiucucu]

Thank you for the answer and for useful links.
What is strange is that it seems the manufacturers "made place" for Processor Serial Number, (CPUID function 3 (EAX=3)), but did not implement it. Why?
I attached a little test application in this long thread (cpuid.zip).
Even the maximum CPUID function reported is 2 (and also PSN flag is '0'), it executes (just for testing) CPUID with EAX=3.
Well, it not chrashes but the results are the same as for function 2.
So, from Processor Serial Number point of view this is garbage

[indiocolifa]

take in consideration that in most motherboards the processor serial number becomes disabled by default, so it's not worth programming anything with a feature that it's useless..

[marsh_pottaye]

Originally Posted by indiocolifa

take in consideration that in most motherboards the processor serial number becomes disabled by default, so it's not worth programming anything with a feature that it's useless..

You mean the motherboards disables the processor serial number, in a hardware way (e.g. by connect a pin to ground)?
Not very clear, please explain more.

[indiocolifa]

I mean that the motherboard BIOS disables the processor serial number (this is configurable with the CMOS Setup) but suppose that you program an application that effectively uses that Serial Number. In fact, in most mobos the default setting is Processor SN : DISABLED.

I do not recommend using this "feature" because : 1) from the end user perspective: many users won't want to touch any obscure CMOS setup 2) this SN feature can issue some privacy problems, and that's the reason why the PIII Serial Number exposition to the outside was so blamed in the past.

[ovidiucucu]

Originally Posted by indiocolifa

I mean that the motherboard BIOS disables the processor serial number (this is configurable with the CMOS Setup) but suppose that you program an application that effectively uses that Serial Number. In fact, in most mobos the default setting is Processor SN : DISABLED.

I do not recommend using this "feature" because : 1) from the end user perspective: many users won't want to touch any obscure CMOS setup 2) this SN feature can issue some privacy problems, and that's the reason why the PIII Serial Number exposition to the outside was so blamed in the past.

Quite clear. Thanks for the aswer!
This is a frequently posted problem in other forums, so I thought this is the best place where it can be clarified for everybody once and forever.

[ovidiucucu]

I have found this interesting comment in another discussion forum:

Originally Posted by Norm Dresner

It was a feature that software sellers desperately wanted to enable
locking a license to a single CPU -- but there was so much outcry from the
software pirates who wanted to be able to steal that software that Intel
caved in to "popular pressure" and made the feature disableable -- which
means that it'll always be disabled. It's unfortunate that the market
caters to thieves.

That's it.

[NoHero]

Don't trust thirdparty information.
Take a look at the Intel Developer Resource:

ftp://download.intel.com/design/Xeon...s/24161827.pdf

The Brand string is a new extension to the CPUID instruction implemented in some Intel IA-32
processors, including the Pentium 4 processor. Using the brand string feature, future IA-32
architecture based processors will return their ASCII brand identification string and maximum
operating frequency via an extended CPUID instruction. Note that the frequency returned is the
maximum operating frequency that the processor has been qualified for and not the current
operating frequency of the processor.
When CPUID is executed with EAX set to the values listed in Table 1, the processor will return
an ASCII brand string in the general-purpose registers as detailed in Table 1.
The brand/frequency string is defined to be 48 characters long, 47 bytes will contain characters
and the 48th byte is defined to be NULL (0). A processor may return less than the 47 ASCII
characters as long as the string is null terminated and the processor returns valid data when
CPUID is executed with EAX = 80000002h, 80000003h and 80000004h.
The cpuid3a.asm program shows how software forms the brand string (see Example 1). To
determine if the brand string is supported on a processor, software must follow the step below:
1. Execute the CPUID instruction with EAX=80000000h
2. If ((returned value in EAX) > 80000000h) then the processor supports the extended CPUID
functions and EAX contains the largest extended function supported.
3. The processor brand string feature is supported if EAX >= 80000004h

[ovidiucucu]

Resolved.