Where is the info returned by the CPUID opcode in x86 permanently stored?

[chrstrbrts]

Hello,

My question is about the CPUID opcode that has been a part of the x86 instruction set for many years now.

I'm familiar with the paradigm:

Place certain bytes in the EAX register and possibly also the ECX register and the CPU will return info in general purpose registers that is meant to be interpreted bit by bit to determine whether the CPU possesses certain features.

My question, though, is where is this info permanently stored?

I have a diagram of all of the registers used in modern x86-64 CPUs, and I can't find a ROM register anywhere that holds information.

Is the info held in non-volatile RAM where the BIOS parameters are stored?

Thanks.

 

[Tuna-Fish]

Firstly,

I have a diagram of all of the registers used in modern x86-64 CPUs,

No. You have a diagram of all the registers used in modern x86-64 cpus, that Intel likes to publicly talk about. They have plenty more than that, they just aren't documented.

More than that, the microcode mechanism contains tens to hundreds of kilobytes of stored data (mostly sequences of uops that replace microcoded ops) that are not directly readable. It also contains the lookup tables used by the transcendental ops, and the cpuid instruction is also microcoded so they might just be inlined in the microcode routine.

 

[VirtualLarry]

The Intel Pentium II Xeon docs talked about a "PI-ROM", that stored things like the processor info bits, PSN (Processor Serial Number), as well as other data. It's the only doc I know that was available publically at one time, that documented these things.

 

[Burpo]

http://www.manualslib.com/manual/397359/Intel-Bfcbase-Motherboard-7300.html?page=119

 

[chrstrbrts]

No. You have a diagram of all the registers used in modern x86-64 cpus, that Intel likes to publicly talk about. They have plenty more than that, they just aren't documented.

Not to question the veracity of your answer, but do you have proof of this?

What other registers do you think Intel has in its processors?

The Intel Pentium II Xeon docs talked about a "PI-ROM", that stored things like the processor info bits, PSN (Processor Serial Number), as well as other data. It's the only doc I know that was available publically at one time, that documented these things.

That processor is decades old now.

I know that the Pentium III had a field returned when CPUID was called with the right argument in EAX that gave the processor's unique serial number.

People complained about the possibility of privacy violation, so Intel took it out and that bit has been adjusted to 0 ever since.

Do you think that Intel still gives its processors a unique serial number stored somewhere on the chip?

Do you think that that serial number, if it exists, is sent out in every outgoing packet when networking?

 

[VirtualLarry]

I know that the Pentium III had a field returned when CPUID was called with the right argument in EAX that gave the processor's unique serial number.

People complained about the possibility of privacy violation, so Intel took it out and that bit has been adjusted to 0 ever since.

Do you think that Intel still gives its processors a unique serial number stored somewhere on the chip?

Yes.

Do you think that that serial number, if it exists, is sent out in every outgoing packet when networking?

No, but that serial number is likely accessable by SMM and / or ME, and could be used when ME is "phoning home".

 

[chrstrbrts]

No, but that serial number is likely accessable by SMM and / or ME, and could be used when ME is "phoning home".

Is SMM System Management Mode?

What's ME?

 

[superstition]

Do you think that Intel still gives its processors a unique serial number stored somewhere on the chip?

Of course, and I'm sure the US government mandates it which is why people should assume AMD processors also have similar tech.

 

[chrstrbrts]

Of course, and I'm sure the US government mandates it which is why people should assume AMD processors also have similar tech.

Do you think that the processor puts that serial number somewhere in the header or payload of outgoing packets?

Also, do you know what ME stands for (look at the above poster's response)?

Thanks.

 

[jhu]

Not to question the veracity of your answer, but do you have proof of this?

What other registers do you think Intel has in its processors?

In 64-bit mode, there are 16 user accessible general purpose registers. Internally, there are significantly more otherwise out of order execution wouldn't work very well.

 

[chrstrbrts]

More than that, the microcode mechanism contains tens to hundreds of kilobytes of stored data (mostly sequences of uops that replace microcoded ops) that are not directly readable. It also contains the lookup tables used by the transcendental ops, and the cpuid instruction is also microcoded so they might just be inlined in the microcode routine.

Yes, but isn't all of that volatile?

That is, doesn't all of that go away when the power is shut off?

 

[Nothingness]

My question is about the CPUID opcode that has been a part of the x86 instruction set for many years now.

I'm familiar with the paradigm:

Place certain bytes in the EAX register and possibly also the ECX register and the CPU will return info in general purpose registers that is meant to be interpreted bit by bit to determine whether the CPU possesses certain features.

My question, though, is where is this info permanently stored?

I have a diagram of all of the registers used in modern x86-64 CPUs, and I can't find a ROM register anywhere that holds information.

Is the info held in non-volatile RAM where the BIOS parameters are stored?

CPUID information is surely placed in some variant of flash memory (on CPU die), since Intel could for instance fully disable TSX, including in CPUID feature bits, with a microcode patch.

 

[chrstrbrts]

CPUID information is surely placed in some variant of flash memory (on CPU die), since Intel could for instance fully disable TSX, including in CPUID feature bits, with a microcode patch.

What's TSX?

Also, what's ME? (see above post)

 

[jhu]

What's TSX?

Also, what's ME? (see above post)

TSX is transactional synchronization extensions. These are mainly useful for databases. Haswell had these extensions and then Intel disabled them in a microcode update because there were bugs in the TSX implementation. I would assume they updated CPUID to reflect this.

ME is the Intel Management Engine. It's a system in the chipset that runs an ARC processor and is used mainly for remote administration purposes. This runs at a higher privilege level than the an OS or even a hypervisor. AMD also has a similar system in place that uses an ARM processor instead of ARC.

 

[Ken g6]

TSX = Transactional Synchronization Extensions.

August 2014, Intel announced that a bug exists in the TSX implementation on Haswell, Haswell-E, Haswell-EP and early Broadwell CPUs, which resulted in disabling the TSX feature on affected CPUs via a microcode update.

I think "ME" refers to the Intel Management Engine, which includes a "secret" non-x86 core on Intel CPUs.

 

[Sheep221]

You will never get to know that stuff, it's an intellectual property protected by various trade secrets etc. It's a technology that has to be protected from intellectual theft and counterfeiting and revealing inner workings of CPUs publicly would also cause serious security threats to x86 computers. x86 is something we will never know exactly how it works, the principles they do teach in courses for electronic engineering are very likely only brief description of how does CPU works. It does tell that CPU executes program instructions, but what really happens on electrical level or machine code level is never gonna be revealed.
The microcode you are asking about is likely to be embedded directly into silicon and is not uploaded post-assembly.

 

[intangir]

MSRs (model-specific registers) exist and companies like Intel or AMD only document some of them for external use. Some configuration values may exist in on-chip read-only memories, but a lot of them can be overridden with different values on boot-up from the BIOS or even from the OS via microcode updates. If you've heard of chicken bits, that's where they live too. That is likely how Intel disabled TSX in Haswell post-release.

https://wiki.debian.org/Microcode

Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update.

The BIOS (or EFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/EFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems.

Please install the amd64-microcode package (for systems with AMD AMD64 processors), or the intel-microcode package (for systems with Intel processors).

Microcode updates will be applied immediately when the microcode packages are installed or updated: you don't have to reboot. You will have to keep the packages installed, though: as explained above, the microcode updates have to be reapplied at every boot.

You can learn more on chicken bits, MSRs, and microcode by watching this great video presented by David Kaplan, security architect at AMD.