4 ms·
This talk from the 32c3 just two weeks ago looks at exactly that problem. They have "chicken bits" (not sure if that's the technical term :)) which can turn off
by ah- 11y ago
This talk from the 32c3 just two weeks ago looks at exactly that problem. They have "chicken bits" (not sure if that's the technical term :)) which can turn off certain features, and they can patch microcode.
https://media.ccc.de/v/32c3-7171-when_hardware_must_just_work https://media.ccc.de/v/32c3-7171-when_hardware_must_just_wor...
Software design and testing is hard, but what happens when each bug fix can cost months of delay and millions of dollars? In this talk we’ll take a behind-the-scenes look at the challenges in the design of a very complex, yet critical piece of hardware: the modern x86 CPU.
- jeswin 11y agoGreat video. Very informative. Thanks.
- rincebrain 11y agoKillbits is the one I've heard most commonly - as the talk says, most modern processors have a bunch because it's impossible to test every possible edge case a priori. (Good recent examples include the AMD lockup bug that Matt Dillon found, and the nasty counter-example of the Intel Quark segfault bug, which can't be worked around so easily because the Quark doesn't have killbits. "Oops.")
- wyager 11y ago>most modern processors have a bunch because it's impossible to test every possible edge case a priori. Only with the sort of engineering most current CPU manufacturers use. It's possible to have formally verified hardware; it's just expensive with current tech. Tools are improving, though. I suspect the next cutting edge will be the unification of functional-language-to-hardware compilers like Clash or Lambda-CCC with fully dependent languages like Agda or Idris, where you can statically verify arbitrary properties though the type system.
- throwupper247 11y agoI've just written an Idris programm that determined "your mothers phone number", hows that for arbitrary facts? (tip of the hat to xkcd.)