[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)



On Sun, 08 Sep 2013, Henrik Ahlgren wrote:
> > or synaptic to look for new tools, right? Or can we just enable those
> > two repositories long enough to load Henrique's tool and the microcode
> > updates, then disable them again?
> 
> Why do you feel that you even need to ask? You are free to handle the
> situation with your machines in any way you wish. Perhaps just

Indeed.  And if you're not going to use the repositories to get automated
updates, you should at least use the Debian PTS (packages.qa.debian.org) to
track package "upload-source" events so that you will get an email when the
package is updated.

> Also, it is hard to argue that it is useful to have the ability to fix
> bugs in the CPU without replacing the chip. After all, you will face

Indeed.  Look at the errata lists for the x86 processors of any vendor...

> Does anyone know if the microcode shipped by Intel is always
> encrypted? Their nasty licence prohibits "everse engineering,

Yes, it is.  And it is not a half-baked job either.
http://inertiawar.com/microcode/

> decompilation, or disassembly" of the blob, but even if you ignored
> that, or even if you had the source code (whatever that means in the
> context of microcode, it is not normal X86 code after all), could you
> make any sense of it without having the whole silicon design
> available?

See here:
http://en.wikipedia.org/wiki/Microcode

You really need a lot of low-level information about the core (and maybe
even the uncore) to do anything useful with the full microcode.

And there is no reason why a microcode update would have the full microcode
inside, either.  It could well be just a "patch" that only describes changed
sections of the microcode, or even a runtime behaviour change table
(something like a hardware breakpoint + microcode that should run when the
breakpoint is activated, or even a table of internal processor state change
that should be applied when the breakpoint is activated, to fix issues that
are not implemented in microcode).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


Reply to: