

Notes on Intel Microcode Updates - robin_reala
http://inertiawar.com/microcode/

======
BigglesZX
Site seems to be down, Google cache (apparently without images, sadly) here:
[http://webcache.googleusercontent.com/search?q=cache:JzPIOfS...](http://webcache.googleusercontent.com/search?q=cache:JzPIOfSB6BQJ:inertiawar.com/microcode/+&cd=1&hl=en&ct=clnk&gl=uk)

~~~
lucb1e
Images don't seem to be cached indeed. They never work in a cached article,
but also when trying to google for
"cache:<http://inertiawar.com/microcode/fig-1-1.png> " it says they're not
cached.

Edit: HN bug? The double-quote sign behind the URL in this post disappears
when I don't put a space in between.

------
atesti
I'm really surprised that Intel seems to have done a good job and really uses
RSA signatures and not some insecure design.

~~~
wladimir
Indeed, it's surprising. I wonder if it has dedicated circuitry to do the
verification, or that it somehow executes a verification program on the
processor itself. I suppose it's the second because the first sounds really
expensive.

~~~
lucb1e
> _The exact cycle value will vary significantly between different types of
> hardware (older hardware was observed to take significantly more cycles)_

This makes me think it uses the CPU itself. Microcode updates are not an
everyday thing and don't need to be fast, they have no reason to update the
circuitry for that. They still might have changed it, but this makes it seems
lightly less likely.

~~~
acallan
This isn't true.

Ucode is updated every time you reset, and on each CPU. At the fab, the
release ucode is burned into the design. But rarely does this last through the
lifetime of a stepping. In fact, one of the main reasons why BIOS/EFI exists
is to update microcode, and this is usually on one of the first things it
does.

From the Intel SDM, Vol III, 9.11.6.1 "The effects of a loaded update are
cleared from the processor upon a hard reset. Therefore, each time a hard
reset is asserted during the BIOS POST, the update must be reloaded on all
processors that observed the reset. The effects of a loaded update are,
however, maintained across a processor INIT. There are no side effects caused
by loading an update into a processor multiple times."

EDIT: I realize you were talking about it being a daily occurrence, and few of
us reboot daily. But still, OEMs and most customers don't want a long boot
time. Also note that in certain power states (deep sleep), the CPU is off, and
waking up your laptop actually will cause a ucode load.

~~~
cfallin
I think the discussion here is missing the fact that "long boot time" is on
the order of milliseconds. From the article: the average time for a ucode
update on the test machine was 489k cycles, which at 2.53GHz is 193
microseconds. I hardly count that as a large part of the boot time...

------
lucb1e
There is one thing that I don't understand:

> _The RSA signature was located, and the signed data is a PKCS#1 1.5 encoded
> hash value. Older processor models use a 160-bit digest (SHA1), and newer
> process models use a 256-bit digest (SHA2)._

Why is it assumed that any random 160-bits digest is SHA1 and any random
256-bits digest SHA-256? I don't know all Merkle-Damgard hashing algorithms by
heart, but are SHA-1 and SHA-256 the only ones using 512-bits blocks and
160/256-bit digest lengths?

