Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Microcode updates are volatile. Rebooting cancels them.


Bad drivers included with the original 8.1 preview builds had a habit of permanently bricking mobile 700 series gpus - I'm sure you could do the same with a microcode update! Imagine setting the default voltage to 5v and multiplier to something crazy high, and disabling thermal cutoff - unless you happen to be dumping LN2 on your cpu at the time, it's probably not going to survive!


Microcode updates shouldn't effect the thermal integrity of the processor.

Microcode updates update a specific part of the processor that does a specific thing, i.e. the translation between the input ISA and the processor's native microcode instruction set, it's not supposed to be a wholesale update of processor parameters. (But we don't know enough about the structure of microcode updates to be certain. But I think you're barking up the wrong tree here and likely should read up on how Intel processors actually use microcode.)

You certainly can brick a CPU by updating parameters like that, but you wouldn't typically update parameters like that via a microcode update.


My microcode experience is some years ago, and nothing nearly as complicated as modern Intel stuff, but depending on just what you can control, you might be able to induce excessive thermal gradients by working some bits flat out and disabling/not dispatching to others. I don't know if the effect would be anything like significant enough to cause damage, although I have seen an excellent project using thermal regional heating to "fingerprint" cores post-fab. I think that required some (but not excessive) physical layout constraints as well.


Modern Intel chips will automatically adjust their clocking if they detect that they're suffering thermal stress. Further, I'm not sure whether microcode has that level of control over dispatch. Especially given the trace cache design of Intel chips, it seems very unlikely that scheduling information would be encoded into the microcode instead of dynamically decided during the out of order execution.

Don't get me wrong, I'm not saying it isn't possible to affect the chip's thermal profile in any way via a microcode update, I'm simply saying it's not the simplest way to do it and I doubt that Intel protects their microcode as fiercely as they do because of thermal concerns.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: