CPUID forgery detection...

[Brendan]

Hi,

I'm currently upgrading some CPU identification code. I've noticed that for a large number of (non-Intel) CPUs it's possible to set some of the values returned by the CPUID instruction.

For an example, it'd be possible for someone to hack a flash BIOS so that an older AMD Athlon is reported as the a much newer CPU in both the BIOS screen and any code that relies on the brand string returned by CPUID.

For some CPUs (e.g. GeodeGX2, which AFAIK can still be bought new) all values returned by CPUID can be programmed, including the vendor ID, family, model, stepping, cache details, brand ID, brand string, etc. In this case it'd be incredibly difficult to determine if the CPU is what it says it is.

I'm thinking it'd be possible to use these CPUs to create cheap forgeries of much more expensive systems, where the BIOS and any OSs report the falsified details. Most unsuspecting buyers would believe what the BIOS and OS (e.g. Windows) tells them without checking the CPU itself.

I haven't heard of this being done before (although I have heard of CPUs being physically modified to look like a more expensive part).

If I spend enough time on my CPU detection code I can implement methods of detecting these forgeries. In some cases I can report correct information (even if CPUID has been forged), and in others I can provide a warning that it's possible that the information isn't correct.

It'd be a nice feature, but it'd also be a pain in the neck to implement.

I guess I'm wondering - should I bother?


Cheers,

Brendan

[chase]

Can you detect that the values have been modified since power up or are you saying you'll have to revert back to pre-CPUID detection methods to identify cpus. Things like presence of opcodes, whacky memory wrapping, etc.

[ucosty]

If a cheap CPU was masquerading as a more full-featured new CPU, wouldn't that mean it would be reporting features that it doesn't have? If thats the case I guess you would have to compare the reported features to the real features (some kind of probe-and-detect) where you look for things like invalid opcodes and handle them accordingly.

[Brendan]

Hi,

Can you detect that the values have been modified since power up or are you saying you'll have to revert back to pre-CPUID detection methods to identify cpus. Things like presence of opcodes, whacky memory wrapping, etc.

It depends on the CPU, what state it's in and what it allows to be changed:

• Transmeta - allows the vendor ID to be changed - easily detected and corrected by trying CPUID with eax = 0x80860000
  AMD - allows the brand string to be set so that the BIOS can add speed ratings, etc. In this case you can follow the same method that the BIOS is meant to use to get the correct brand string and ignore the original.
  IDT/Centaur - allows the family, model, stepping and vendor ID to be changed. They can be detected using CPUID with eax = 0xC0000000. The family, model and stepping can be determined from the feature flags.
  NSC/Geode - the GX1 is OK. The GX2 allows everything returned by CPUID to be programmed. There's some "write-once" MSRs for this, so you can try to change the values and if they can't be changed you know someone already changed them. For each MSR that couldn't be changed you'd restore default settings - the only thing that can't be recovered is the stepping, but that doesn't matter too much.

If a cheap CPU was masquerading as a more full-featured new CPU, wouldn't that mean it would be reporting features that it doesn't have? If thats the case I guess you would have to compare the reported features to the real features (some kind of probe-and-detect) where you look for things like invalid opcodes and handle them accordingly.

It's more for getting the right brand string and vendor - most users wouldn't know enough to check the family, model, stepping, etc or different feature flags. Of course the manufacturers themselves don't make this easy - different CPUs with the same family, model, stepping, and family numbers that go from 6 (Pentium Pro/II/III/M) to 15 (Pentium 4) and then back to 6 again (Core, Core2).

My software needs correct information too. For e.g. if a Transmeta is set to look like a Pentium to trick software into using it (there are valid reasons to do this), then my code will apply Intel's errata to it and decide it's got the F00F bug and a pile of other problems (rather than the problems it does have, like RDTSC roll-over). In this case my OS will try to fix problems that don't exist and might crash because of problems that do exist...


Cheers,

Brendan

[Mikae]

It'd be a nice feature, but it'd also be a pain in the neck to implement.

I guess I'm wondering - should I bother?

From the point of view of benefits -- I am not sure that users will be interested in. CPU forgery is impossible if you buy an 'alone' CPU, without motherboard. In this case, all forgeries, cause they are made to BIOS will be lost.

[Candy]

Think it's better if you didn't. Consider users that find out your XYZ product detection is flawed and crashes on their new CPU's. Resetting the cpuid to intel fixes the problem. You'd be making software that works around hacks, which is pretty much the cause of 90% of all crashes nowadays, as well as about 90% of all code...

[raistlinthewiz]

this is really nice discussion adding to my bookmarks. My kernel project heavly implies on CPUID. Please update the topic if you even got more info.

[Brendan]

Hi,

Think it's better if you didn't. Consider users that find out your XYZ product detection is flawed and crashes on their new CPU's. Resetting the cpuid to intel fixes the problem. You'd be making software that works around hacks, which is pretty much the cause of 90% of all crashes nowadays, as well as about 90% of all code...

IMHO for a "commercial quality" OS, assuming CPUID is correct and not implementing CPU specific work-arounds is a mistake.

For me "CPU detection" means finding which features the CPU supports (not which features it says it reports), finding CPU bugs that can be avoided (and avoiding them), finding CPU bugs that can't be avoided (and letting system administrators know), finding cache sizes (to optimize memory management), detecting CPU topology (multi-core with shared caches, hyper-threading, etc - used to optimize scheduling), finding power management features, etc.

None of this can work reliably if the CPU is giving false information.

Changing a CPU to work-around software bugs is a bad idea because software can be easily fixed. Changing software to work-around CPU bugs is unavoidable because hardware can't be fixed.


Cheers,

Brendan

[rexlunae]

IMHO for a "commercial quality" OS, assuming CPUID is correct and not implementing CPU specific work-arounds is a mistake.

I think this is a completely backwards idea. If the CPU is faking its identity, it's probably for a good reason. When someone implements a hack like misreporting the processor's identity, they take responsibility for the problems it may create.

If you try to defeat this CPU spoofing, it will prompt the people doing the spoofing to come up with better spoofing, and then you will have to work around their better spoofing, all the while making the whole system more complex, creating more opportunities for bugs, and creating an endless stream of pointless work for both sides.

I'm not aware of this being done large-scale anywhere, but I recommend that if it's a problem, you simply state that your OS is tested and expected to work on those processors which behave reasonably and don't claim to have features which they don't have.

[JAAman]

i see a big difference between compensating for CPU 'bugs', (which really should be there), and attempting to defeat CPU 'hacking'

bugs are accidental -- identify them, and workarounds for them
but CPU 'spoofing' is intentional -- someone wants you to believe that the CPU is something it isnt, and sometimes there are good reasons for this, attempting to 'uncover' this, doesnt serve anyone, and can make more problems

[smiddy]

Brendan,

I think this is a great science project. I personally ran into my BIOS inadvertantly re-naming my AMD to the wrong version based on speed. This was discouraging since I paid for a processor and began to think I had another one, until that is, I began looking into it further. My particular issue was I didn't have the correct RAM to use the CPU at its full speed, thus the BIOS did its thing. When I put the correct speed RAM into the box, the BIOS didn't try to re-name it back, so I had to remove what was written by the BIOS and allow it to do its thing again. With the new RAM in it renamed it to what it should have been to begin with.

I also agree with ruxlunae, this can get rather complex, but if you're relying on specific features and you want to insure they are there prior to having your code burp the wrong opcodes, it makes full sense to me. I, like yourself (not as good as your...yet) am doing more checks to inform the user of the particular device currently available for use on their machines. I use a device manager (not as indept as your own...yet) to evaluate the devices and then make the choices to do certain opcodes based on that knowledge. I think it makes perfect sense to know and if a particular items isn't available that you need to run your OS, your OS should make a graceful exit, or at least announce the issue and identify the limitations based on that. This to me is smart programming. I know other will disagree with this...but that is my own take.

[Candy]

IMHO for a "commercial quality" OS, assuming CPUID is correct and not implementing CPU specific work-arounds is a mistake.

That's a bit of an odd thing you should mention. In my opinion, something I buy should work for me and not hold me back. It should not give me a reason to mess about with the cpu information, and if I do then it should both react accordingly and mess up accordingly. Only stuff for manager-ish types and home users should try to protect the user no matter what. Changing your CPU identification is something those types don't do, so I consider changing the OS to ignore what the CPU says to be evil, except when the cpu itself is unintentionally wrong It's ok to test whether what the CPU says is true, but it's not ok to assume "it says intel, could be transmeta, let's figure out what it really is and run the code we want to" since the user explicitly overrides it.

For me "CPU detection" means finding which features the CPU supports (not which features it says it reports), finding CPU bugs that can be avoided (and avoiding them), finding CPU bugs that can't be avoided (and letting system administrators know), finding cache sizes (to optimize memory management), detecting CPU topology (multi-core with shared caches, hyper-threading, etc - used to optimize scheduling), finding power management features, etc.

None of this can work reliably if the CPU is giving false information.

The CPU should give reliable information unless told by a human not to, at their own risk.

Changing a CPU to work-around software bugs is a bad idea because software can be easily fixed. Changing software to work-around CPU bugs is unavoidable because hardware can't be fixed.

True, but the cpu's have already been changed to work around arrogant programmers and designers as well as business plans for arbitrarily restricting competition.

[JAAman]

I consider changing the OS to ignore what the CPU says to be evil, except when the cpu itself is unintentionally wrong It's ok to test whether what the CPU says is true, but it's not ok to assume "it says intel, could be transmeta, let's figure out what it really is and run the code we want to" since the user explicitly overrides it.

i definitely agree with this point this is basically what i was trying to say, except im not as good at saying what i want to say

[Brendan]

Hi,

If you try to defeat this CPU spoofing, it will prompt the people doing the spoofing to come up with better spoofing, and then you will have to work around their better spoofing, all the while making the whole system more complex, creating more opportunities for bugs, and creating an endless stream of pointless work for both sides.

Changing the details reported by some CPUs is easy - anyone can download the information needed to do it, and usually you only need to write some new values to some MSRs. If this is detected/prevented then the only option left for the spoofer is messing with micro-code updates, which isn't something the average script kiddie is capable of (to my knowledge, there is no information available for this, except for some reverse engineered details for Transmeta Crusoe/TM5800 "code morphing software" that isn't really suitable or enough for a viable spoof).

That's a bit of an odd thing you should mention. In my opinion, something I buy should work for me and not hold me back. It should not give me a reason to mess about with the cpu information, and if I do then it should both react accordingly and mess up accordingly. Only stuff for manager-ish types and home users should try to protect the user no matter what. Changing your CPU identification is something those types don't do, so I consider changing the OS to ignore what the CPU says to be evil, except when the cpu itself is unintentionally wrong It's ok to test whether what the CPU says is true, but it's not ok to assume "it says intel, could be transmeta, let's figure out what it really is and run the code we want to" since the user explicitly overrides it.

"It says Intel, but could be Transmeta - let's figure out what it really is and use the F00F bug work-around if it's an Intel Pentium, and the RDTSC bug work-around if it's a Transmeta". If I assume it's an Intel when it's not, you end up with a pointless work-around and erratic software.

Should I trust my software's abilities, or modifications an unknown user made for unknown reasons? I guess it depends on why the CPUID information was altered....

If it's done to avoid bugs in badly written software then it's a waste of time for my OS - I'll have different bugs than other software, and if they're trying to avoid my bugs it's better to let me know so I can fix them.

If it's done to hide bugs in the CPU then it's pointless. My OS should detect the bug anyway (and if it doesn't, then my code is faulty and should be fixed).

If the CPU has been accidentally misconfigured or deliberately misconfigured to mislead people (e.g. a scammer trying to sell something as something else), then detecting/recovering from this is a good idea.


Cheers,

Brendan

[rexlunae]

Changing the details reported by some CPUs is easy - anyone can download the information needed to do it, and usually you only need to write some new values to some MSRs. If this is detected/prevented then the only option left for the spoofer is messing with micro-code updates, which isn't something the average script kiddie is capable of (to my knowledge, there is no information available for this, except for some reverse engineered details for Transmeta Crusoe/TM5800 "code morphing software" that isn't really suitable or enough for a viable spoof).

They could always release new hardware that does a better job of preventing you from detecting the processor's true identity. At a certain point, you just have to say that your software may not work on broken hardware. CPUID is a nice, clean way to figure out what you can expect from a processor, unlikely to encourage bugs, and if that processor attempts to trick the OS, it can't be expected to work.

Keep in mind that there's a flip side to this: If you have code that tries to determine what type of processor you're dealing with by a more obscure mechanism, there is a higher chance of bugs causing misdetection, which could cause behavior that is just as bad as the potential problem you're trying to work around.