5 ms·

I wonder what is the attack scenario that the RSA signature of the microcode is supposed to protect? An attacker flashing a microcode that introduces specially-

• rdl 13y ago
  Bricking your $3000 CPU?
  • mrb 13y ago
    Microcode updates are volatile. Rebooting cancels them.
    • DuskStar 13y ago
      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!
      • djcapelis 13y ago
        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.
        • shabble 13y ago
          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.
          • djcapelis 13y ago
            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.
  • deleted 13y ago
    [deleted]
• djcapelis 13y ago
  That's one, but another scenario you forgot about is one where researchers would just fuzz the microcode update mechanism to try and figure out more about how the insides of the processor work. If you could get the processor to recognize your microcode updates as valid, you could determine information about how the processor deals with microcode internally by observing what changes after you send different update sequences. Intel protects their trade secrets pretty fiercely and they don't talk about the processor's internal microcode representation. As much as many of us would really like them to let us know what's really going on inside there.
• deleted 13y ago
  [deleted]