5 ms·

> features are retrieved by using the cpuid instruction. *Unfortunately this instruction is privileged for some architectures, in which case we fall back to Lin

> features are retrieved by using the cpuid instruction. *Unfortunately this instruction is privileged for some architectures, in which case we fall back to Linux. What's the rationale for making this instruction privileged for the other procs? I can kinda understand making system registers privileged reads but if you have your own encoding there's "no reason" not to give this to everyone, right?

valarauca1 9y ago
several 1. Malware can infer details from CPUID to guess if it’s in a VM or not. Useful to avoid detection/analysis. 2. When processes execute in a legacy mode you may trap on CPUID to hide details the library won’t understand, or doesn’t expect to exist. To avoid backwards compatibility issues... better safe then sorry. 3. When developing SIMD related libraries which need to be portable across multiple CPU versions you may set up a CPUID mask (so trap, then hide features) to ensure compatibility on legacy computers. Overall having the ability to trap, and rewrite the CPUID instruction is incredibly useful. The difference between denying, and rewriting just boils down to if a callback is provided or not. Both features require disabling native CPUID execution.
- dbaupp 9y ago
  > 3. When developing SIMD related libraries which need to be portable across multiple CPU versions you may set up a CPUID mask (so trap, then hide features) to ensure compatibility on legacy computers. Huh? My impression was CPUID was exactly the opposite: using it properly allows ensuring compatibility on older computers while still getting maximum performance, since one can dynamically dispatch to an implementation that uses only what is supported. (E.g. switch between an SSE2 version and an AVX version.)
  - jcranmer 9y ago
    Your impression is correct.
  - haberman 9y ago
    I think GP is saying that unit tests for such dynamically-dispatching code will want to be able to inject older CPUIDs, so the compatibility fallbacks have test coverage. If CPUID is a native instruction, it's harder to inject a fake value. I'm not sure I find this compelling though. It's easy to make your own CPUID function that doesn't actually call "CPUID" in a test build.
- jcranmer 9y ago
  CPUID on x86 is a user-level instruction. When you're doing processor-assisted emulation, CPUID is an instruction that does cause an exit to the hypervisor, which does allow you to do CPUID emulation. You clearly don't need such instructions to be privileged to do emulation games with CPUID.
  - valarauca1 9y ago
    >You clearly don't need such instructions to be privileged to do emulation games with CPUID. There are configuration registers which can make CPUID a privileged instruction.
white-flame 9y ago
If they give uniquely identifying chip serial numbers, that'd be reason to keep it secure.
- awalton 9y ago
  Intel doesn't do this anymore: https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_privacy_issues https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_...
jcranmer 9y ago
The complex CPUID instruction is, to my knowledge, unique to x86 processors. The equivalents for other processors are essentially special machine status registers that set bits appropriately. The main reason that these are privileged is probably because: a) The main use of these is checking if you've got floating-point and/or vector unit support. This support requires the OS to know about this information anyways (imagine if your OS didn't bother to save/restore these registers on context switches!), so making the OS check this information is not difficult. b) There's generally already a fairly generic mechanism for stuffing OS-level special-purpose registers that's fairly unbounded in size, so it's essentially free to add an addressing of these specific registers in that mode. Making some of these registers be legal in user-space code is more expensive in hardware size and complexity, and (as mentioned earlier) the OS has to be modified anyways to take advantage, so requiring the OS to report these details to userspace code isn't problematic. c) For RISC processors, you've generally got a fairly full opcode space anyways. Taking up an opcode for a very niche functionality that isn't particularly necessary isn't a good use of scarce extra space.

valarauca1 9y ago

several 1. Malware can infer details from CPUID to guess if it’s in a VM or not. Useful to avoid detection/analysis. 2. When processes execute in a legacy mode you may trap on CPUID to hide details the library won’t understand, or doesn’t expect to exist. To avoid backwards compatibility issues... better safe then sorry. 3. When developing SIMD related libraries which need to be portable across multiple CPU versions you may set up a CPUID mask (so trap, then hide features) to ensure compatibility on legacy computers. Overall having the ability to trap, and rewrite the CPUID instruction is incredibly useful. The difference between denying, and rewriting just boils down to if a callback is provided or not. Both features require disabling native CPUID execution.

dbaupp 9y ago
> 3. When developing SIMD related libraries which need to be portable across multiple CPU versions you may set up a CPUID mask (so trap, then hide features) to ensure compatibility on legacy computers. Huh? My impression was CPUID was exactly the opposite: using it properly allows ensuring compatibility on older computers while still getting maximum performance, since one can dynamically dispatch to an implementation that uses only what is supported. (E.g. switch between an SSE2 version and an AVX version.)
- jcranmer 9y ago
  Your impression is correct.
- haberman 9y ago
  I think GP is saying that unit tests for such dynamically-dispatching code will want to be able to inject older CPUIDs, so the compatibility fallbacks have test coverage. If CPUID is a native instruction, it's harder to inject a fake value. I'm not sure I find this compelling though. It's easy to make your own CPUID function that doesn't actually call "CPUID" in a test build.
jcranmer 9y ago
CPUID on x86 is a user-level instruction. When you're doing processor-assisted emulation, CPUID is an instruction that does cause an exit to the hypervisor, which does allow you to do CPUID emulation. You clearly don't need such instructions to be privileged to do emulation games with CPUID.
- valarauca1 9y ago
  >You clearly don't need such instructions to be privileged to do emulation games with CPUID. There are configuration registers which can make CPUID a privileged instruction.

white-flame 9y ago

If they give uniquely identifying chip serial numbers, that'd be reason to keep it secure.

awalton 9y ago
Intel doesn't do this anymore: https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_privacy_issues https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_...

jcranmer 9y ago

The complex CPUID instruction is, to my knowledge, unique to x86 processors. The equivalents for other processors are essentially special machine status registers that set bits appropriately. The main reason that these are privileged is probably because: a) The main use of these is checking if you've got floating-point and/or vector unit support. This support requires the OS to know about this information anyways (imagine if your OS didn't bother to save/restore these registers on context switches!), so making the OS check this information is not difficult. b) There's generally already a fairly generic mechanism for stuffing OS-level special-purpose registers that's fairly unbounded in size, so it's essentially free to add an addressing of these specific registers in that mode. Making some of these registers be legal in user-space code is more expensive in hardware size and complexity, and (as mentioned earlier) the OS has to be modified anyways to take advantage, so requiring the OS to report these details to userspace code isn't problematic. c) For RISC processors, you've generally got a fairly full opcode space anyways. Taking up an opcode for a very niche functionality that isn't particularly necessary isn't a good use of scarce extra space.