3 ms·

I'm curious: what would a fix for these look like? Does it mean a new revision to be bought, a recall, a software patch?

by tgb 11y ago

felixfurtak 11y ago
presumably just a microcode update
iwwr 11y ago
You don't fix them, the tools and systems (gcc or the operating systems) have to work around them (i.e. not allow the sequences of instructions that generate the bad behaviour).
- rincebrain 11y ago
  That's one way, and sometimes the only way on certain platforms (hello Intel Quark), but - those kinds of workarounds can cause problems on other platforms in turn - they don't stop malicious people from making use of such exploits, if they don't require such privileges as to make them pointless once you can use them So you generally prefer to be able to update the CPU microcode or flip a killbit to disable the relevant silicon path, to having to recompile everything on your architecture to include a workaround detection.
colejohnson66 11y ago
Usually just a microcode update. Before microcode though, a bug would usually just be worked around. IIRC, Windows would actually trap the FDIV instruction on buggy Pentiums and compute the true result with software. With enough pressure, a recall might be issued, but it took a while for Intel to finally recall the buggy Pentiums.
- wglb 11y ago
  For the FDIV bug, IBM pulled and replaced all shipped bad chips. Not every vendor did that.
  - sehugg 11y ago
    Only after the bug was described on CNN.
  - dspillett 11y ago
    The FDIV bug was an oddity in part because of when it happened. It was the first significant bug not fixable by microcode update or similar in the first Intel chip to be marketed directly at the end user. Marketing/PR was a key factor: public awareness was high, public understanding was low, and the press had a field day showing examples of the bug affecting popular spreadsheet applications. Prior to the Pentium line, CPUs were something only techie users like us were more than casually aware of - to everyone else they were just a part in an appliance and bugs like this would have been blamed on the software (for which there would be an update to work around the bug which would cement the opinion the software was the source of the problem). Traditionally kernels and compilers would be reissued with a work-around (and software affected by a complier change patched) and people who were significantly affected (number crunchers for who the workaround massively affected performance in this case) might get a replacement if they bought direct from Intel. Home and office users would be pretty much unaware of this happening. There were a number of bugs in x86 chips prior to this that were handled that way (see the list of bugs the Linux kernel checks for on startup like "FOOF" and so forth). Obviously this isn't just an Intel thing, I expect all significant processor lines have had bugs. I remember some machine code I'd badly crafted being affected by a bug in some variants of the 6502 so it would work on some BBCs/compatible but not all (I forget the exact details but it was something about jumps from locations at the last byte of a page, the workaround was easy: pad the location or to use the mallet instead of a more precise tool and 16-bit align everything).
quanticle 11y ago
It depends on the severity of the bug and the level of foresight of the hardware designer. In the worst case (e.g. the FDIV bug on the Pentium) you have to recall the CPU. Obviously, this is very bad. That's why modern CPUs have what are called "chicken bits" or "kill bits", which the BIOS or OS can set to disable specific features. The most recent use of kill bits I can recall is Intel disabling the TSX instructions on the Haswell line of CPUs. Finally, the least invasive option is to issue a microcode update, alters the way that x86 instructions get decoded to avoid the problematic behavior. Microcode updates are issued as software patches, and they're actually in the Linux kernel source tree. If you want to learn more about all three of these fix techniques, in addition to learning a bit about the steps that Intel and AMD take to prevent such bugs in the first place, I highly recommend this CCC talk: https://media.ccc.de/v/32c3-7171-when_hardware_must_just_work https://media.ccc.de/v/32c3-7171-when_hardware_must_just_wor....
- rincebrain 11y ago
  Don't forget the Segfault bug on the Intel Quark (which doesn't have killbits - oops) [1], or the stack pointer overflow bug that Matt Dillon found compiling DragonflyBSD [2], or the Barcelona "you weren't really using your TLB, were you?" cache coherency bug [3]. Microcode is also in multiple places - there's a flavor baked into your chip, flavors baked into your BIOS to boot on your CPU if its rev is lower, and flavors pushed into {Windows,Linux,...} that also flash if their revs are newer. [1] - https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug [2] - http://wiki.osdev.org/CPU_Bugs#DragonFly_BSD_Heavy_Load_Crash http://wiki.osdev.org/CPU_Bugs#DragonFly_BSD_Heavy_Load_Cras... [3] - http://www.anandtech.com/show/2477/2 http://www.anandtech.com/show/2477/2

I'm curious: what would a fix for these look like? Does it mean a new revision to be bought, a recall, a software patch?

by tgb 11y ago

I'm curious: what would a fix for these look like? Does it mean a new revision to be bought, a recall, a software patch?

felixfurtak 11y ago

presumably just a microcode update

iwwr 11y ago

You don't fix them, the tools and systems (gcc or the operating systems) have to work around them (i.e. not allow the sequences of instructions that generate the bad behaviour).

rincebrain 11y ago
That's one way, and sometimes the only way on certain platforms (hello Intel Quark), but - those kinds of workarounds can cause problems on other platforms in turn - they don't stop malicious people from making use of such exploits, if they don't require such privileges as to make them pointless once you can use them So you generally prefer to be able to update the CPU microcode or flip a killbit to disable the relevant silicon path, to having to recompile everything on your architecture to include a workaround detection.

colejohnson66 11y ago

Usually just a microcode update. Before microcode though, a bug would usually just be worked around. IIRC, Windows would actually trap the FDIV instruction on buggy Pentiums and compute the true result with software. With enough pressure, a recall might be issued, but it took a while for Intel to finally recall the buggy Pentiums.

wglb 11y ago
For the FDIV bug, IBM pulled and replaced all shipped bad chips. Not every vendor did that.
- sehugg 11y ago
  Only after the bug was described on CNN.
- dspillett 11y ago
  The FDIV bug was an oddity in part because of when it happened. It was the first significant bug not fixable by microcode update or similar in the first Intel chip to be marketed directly at the end user. Marketing/PR was a key factor: public awareness was high, public understanding was low, and the press had a field day showing examples of the bug affecting popular spreadsheet applications. Prior to the Pentium line, CPUs were something only techie users like us were more than casually aware of - to everyone else they were just a part in an appliance and bugs like this would have been blamed on the software (for which there would be an update to work around the bug which would cement the opinion the software was the source of the problem). Traditionally kernels and compilers would be reissued with a work-around (and software affected by a complier change patched) and people who were significantly affected (number crunchers for who the workaround massively affected performance in this case) might get a replacement if they bought direct from Intel. Home and office users would be pretty much unaware of this happening. There were a number of bugs in x86 chips prior to this that were handled that way (see the list of bugs the Linux kernel checks for on startup like "FOOF" and so forth). Obviously this isn't just an Intel thing, I expect all significant processor lines have had bugs. I remember some machine code I'd badly crafted being affected by a bug in some variants of the 6502 so it would work on some BBCs/compatible but not all (I forget the exact details but it was something about jumps from locations at the last byte of a page, the workaround was easy: pad the location or to use the mallet instead of a more precise tool and 16-bit align everything).

quanticle 11y ago

It depends on the severity of the bug and the level of foresight of the hardware designer. In the worst case (e.g. the FDIV bug on the Pentium) you have to recall the CPU. Obviously, this is very bad. That's why modern CPUs have what are called "chicken bits" or "kill bits", which the BIOS or OS can set to disable specific features. The most recent use of kill bits I can recall is Intel disabling the TSX instructions on the Haswell line of CPUs. Finally, the least invasive option is to issue a microcode update, alters the way that x86 instructions get decoded to avoid the problematic behavior. Microcode updates are issued as software patches, and they're actually in the Linux kernel source tree. If you want to learn more about all three of these fix techniques, in addition to learning a bit about the steps that Intel and AMD take to prevent such bugs in the first place, I highly recommend this CCC talk: https://media.ccc.de/v/32c3-7171-when_hardware_must_just_work https://media.ccc.de/v/32c3-7171-when_hardware_must_just_wor....

rincebrain 11y ago
Don't forget the Segfault bug on the Intel Quark (which doesn't have killbits - oops) [1], or the stack pointer overflow bug that Matt Dillon found compiling DragonflyBSD [2], or the Barcelona "you weren't really using your TLB, were you?" cache coherency bug [3]. Microcode is also in multiple places - there's a flavor baked into your chip, flavors baked into your BIOS to boot on your CPU if its rev is lower, and flavors pushed into {Windows,Linux,...} that also flash if their revs are newer. [1] - https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug [2] - http://wiki.osdev.org/CPU_Bugs#DragonFly_BSD_Heavy_Load_Crash http://wiki.osdev.org/CPU_Bugs#DragonFly_BSD_Heavy_Load_Cras... [3] - http://www.anandtech.com/show/2477/2 http://www.anandtech.com/show/2477/2