Processor identity: CPUID
CPUID is the query a program puts to the processor, and the processor answers for itself: the name of its maker, the brand string that spells out the model, the family, model and stepping that place the part in a product line, the instruction sets it supports, the count of cores and threads, and a flag that says a hypervisor is underneath. Any program on the system can ask and read all of it. A web page cannot ask at all, and lives on the much shorter summary the browser gives it.
What the processor says about itself
The description comes from the part itself, not from a file and not from a driver. A program issues the query instruction, the processor answers in registers, and anything else on the system can ask the same thing. One answer is a short fixed string naming the maker; another is the brand string, the readable model name printed on the part. Family, model and stepping place it in a design generation, a model within that generation, and a revision of that model. A row of feature bits states which optional capabilities it implements, from vector arithmetic to the instructions that accelerate encryption. Further queries describe the cache levels and the way cores and threads are numbered. One range of queries is reserved by convention for a hypervisor, and on physical hardware nothing meaningful answers there.
How websites see it
No browser hands a page the processor description: nothing in the web interfaces returns the maker string, the brand string, the family and model, the feature bits or the caches, and the hypervisor flag is not exposed either. What a page gets is a summary and a set of side effects. Scripts read how many logical processors the browser is prepared to admit to, and some browsers add an approximate figure for system memory, rounded and capped on purpose. The platform, and in some browsers the architecture and the word width, can be asked for through the user agent. The graphics adapter names itself through the drawing interfaces, and the speed of a small computation can be measured, although the timers a page is given are deliberately coarse. Profiling scripts fold that into a fingerprint of the visitor's system and look for disagreements: a thread count that does not fit the claimed platform, an architecture that contradicts the graphics stack, a speed that does not match the story.
How installed software sees it
A program installed on the system is not held to that summary. On the architecture most desktop systems use, the query is an ordinary instruction that needs no privilege: any program can execute it and read the whole answer. Where the equivalent registers are privileged, the operating system reads them and publishes the result in its own inventory of the hardware. Either way the brand string, the family, model and stepping, every feature bit, the cache and thread layout and the hypervisor flag are within reach, and desktop applications, launchers and the security components of online services read them when they decide what they are running on.
Why it matters for a virtual machine
A virtual machine has no processor of its own: it runs on the host's, and the hypervisor decides what the guest may learn. Much of the answer passes straight through, so the brand string read inside a virtual machine usually names the host's part. The hypervisor also edits. It can hide feature bits so the guest stays able to move to an older host, it sets the flag that announces its presence, and it fills the reserved range of queries with a name of its own, where a guest looks for paravirtual services. Each of those says plainly that the environment is virtual, and switching them off leaves marks instead: a brand string naming a model whose known features do not match the bits reported, a count of cores and threads that does not fit that model. Timing is harder to hide, since a query the processor answers alone is quick and one the hypervisor must intercept is not. This is why the processor identity is part of the hardware identity the environment in this tour presents as a whole, in agreement with the system configuration and the rest of the PC.
What this stop of the tour shows
In this scene the camera moves to the processor and opens its answer as a readable card: the maker, the brand string, the family, model and stepping, the instruction sets, the cores and threads, and the hypervisor line that a physical part leaves clear. The card is drawn on the page rather than painted into the video, so it can be read without the animation. The next stop turns to location, and to the receiver that reports where the PC is.
| Field | What it says |
|---|---|
| Vendor | A short fixed string naming the maker of the part, and the key to how the rest of the answer should be read. |
| Brand string | The readable model name the maker gives the part. A hypervisor commonly passes the host's string through unchanged. |
| Family, model and stepping | Fields placing the part in a design generation, a model within it, and a revision of that model. |
| Instruction sets | A row of bits, one for each optional capability. A hypervisor can clear the ones it does not want a guest to use, leaving a model whose own features are missing. |
| Cores and threads | How many cores the part has and how many hardware threads they present. The only part of the description a browser reports, as a count some browsers cap. |
| Hypervisor flag | A bit the processor leaves clear and a hypervisor sets to say the guest is virtual. Beside it sits the reserved range where a hypervisor names itself. |