Notes on Intel Microcode Updates(inertiawar.com)
inertiawar.com
Notes on Intel Microcode Updates
http://inertiawar.com/microcode/
9 comments
Site seems to be down, Google cache (apparently without images, sadly) here: http://webcache.googleusercontent.com/search?q=cache:JzPIOfS...
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.
Edit: HN bug? The double-quote sign behind the URL in this post disappears when I don't put a space in between.
I'm really surprised that Intel seems to have done a good job and really uses RSA signatures and not some insecure design.
A couple of things (I work for Intel, and do not speak for them):
-A ucode hack would be the ULTIMATE backdoor
-A ucode hack could damage or destroy (melt) the part. Think of things like thermal diode trim values, voltage, etc.
Intel had a billion-dollar lesson with recalls in the past, and the learning wasn't lost.
-A ucode hack would be the ULTIMATE backdoor
-A ucode hack could damage or destroy (melt) the part. Think of things like thermal diode trim values, voltage, etc.
Intel had a billion-dollar lesson with recalls in the past, and the learning wasn't lost.
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.
> 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.
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.
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.
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.
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...
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?
> 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?