

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

======
kens
It's amazing how much someone can determine about a "secure" system by poking
at it, doing differential attacks, and timing attacks. Anyone trying to build
something secure should take warning from this, especially since there are
much, much more determined attackers.

As someone reverse-engineering the Z-80, I find this article interesting.
Maybe 35 years from now, someone will post a full analysis of how this Intel
chip processes microcode internally, answering all the questions raised by
this article. It will be very interesting to find out if there's anything
malicious in any microcode patches. Are there checksums of the microcode so
you can make sure you're not getting "special" microcode updates?

Reply to mrb: I expect 90% of the purpose of the signature is to protect
against untested or corrupted updates getting installed. (It would be a
support nightmare if people installed microcode with errors.) Protecting
against deliberate attacks is probably secondary; I doubt you could do a
nontrivial attack without inside help.

~~~
akira2501
Fortunately, microcode updates are not persistent across boots.

~~~
nly
And how do we know that is really the case? It could be partially persistent
and you'd never know it.

~~~
akira2501
To do that it would require some type of persistent memory on the CPU itself.
You could open the chip and look for memory of this type, it requires certain
special features to operate, and they're somewhat easy to pick out of a chip
shot.

There's also an engineering reason to avoid doing this: persistent memory
cells based on silicon have a limited number of write cycles.

------
spydum
I find analysis like this thoroughly fascinating. I wonder if the handful of
Intel engineers who presumably crafted this would ever stumble into this post.
Would they be impressed, or alarmed that someone is probing such a crucial
mechanism?

~~~
djcapelis
Having talked with some Intel engineers about their microcode, they consider
it a company secret that protects trade secrets about how their processors
function and wouldn't say much of anything about it.

I suspect they would be slightly impressed that someone was able to find out
as much as they did, but I don't think they would be overly surprised. I also
suspect they would also be satisfied that this doesn't disclose anything
sensitive about the _contents_ of the microcode updates and just found out
some information about the mechanism.

They definitely wouldn't be surprised that someone was probing microcode
updates. A lot of us have asked them about it and they know people are
interested about what's going on inside those blobs.

> I wonder if the handful of Intel engineers who presumably crafted this would
> ever stumble into this post.

They almost certainly will if they haven't already.

~~~
smalley
Yup, a lot of folks at the office enjoy skimming hacker news, ars technica
etc. The number of people capable of actually signing microcode even in a
company of 100,000+ is pretty darn small though.

You'd actually be surprised about how much effort goes into hardening things
against attacks like those these days (timing attacks, differential power
analysis etc). There's a lot of interesting work around on the best ways of
mitigating those risks.

------
mrb
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-crafted bugs in certain instructions, in order to create backdoors?

~~~
rdl
Bricking your $3000 CPU?

~~~
mrb
Microcode updates are volatile. Rebooting cancels them.

~~~
DuskStar
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
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
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
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.

------
taway2012
Can somebody explain what extra security they gained by using an RSA-based
signature as opposed to a straight-up HMAC (with the secret key burned into
the CPU)?

~~~
caf
This way all the CPUs out there contain the information required to verify an
update, but not the information required to create a verifiable update. If
there was a secret key burned into the CPU, you can be sure that it would
eventually be discovered.

~~~
taway2012
Maybe I'm missing something: the public key is present in the microcode update
blob (according to the article), and CPU itself must have corresponding
private key within it. The sender uses the public key to sign, the receiver
uses the private key to verify.

If we stipulate that info burned into the CPU isn't secure against extraction,
then an attacker can get the private key. Obviously, he can obtain the public
key much more easily from then update blob.

And now they can generate malicious updates.

The security of even the RSA system seems to rest on the difficulty of
extracting the private key from the CPU.

Am I missing something?

~~~
caf
You do not sign with a public key; you sign with a private key and verify with
a public key.

The presence of a public key within the update itself indicates that that
public key must somehow be authenticated by the CPU. Two possible options are
that the public key itself is signed by a master key, and the "master" public
key is embedded within the CPU; or that the cryptographic hashes of all valid
public keys are directly embedded within the CPU. The point of the second
option would be to save area on the CPU die (a 256 bit hash can be saved in
place of a 2048 bit public key).

~~~
taway2012
Thanks, I think I understand now. The chip verifies the update using the
public key present in the blob. But before doing so, it checks the public key
against some whitelist of valid public keys.

The private key used to sign the blob is never present on the chip.
Interesting. Seems pretty secure to me, and more secure than a straight-up
HMAC.

Thanks for answering my questions. I know a little about symmetric crypto, and
your explanation has been very useful to expand my knowledge.

------
andyjohnson0
Some previous discussion on this:
[https://news.ycombinator.com/item?id=5485035](https://news.ycombinator.com/item?id=5485035)

Also:
[https://news.ycombinator.com/item?id=5351672](https://news.ycombinator.com/item?id=5351672)

------
ffrryuu
The NSA probably got the private key so they can reprogram your CPU.

~~~
zokier
I would be quite impressed if NSA had the ability to write microcode updates
themselves. I'd imagine they are not exactly trivial and require intimate
knowledge of the actual silicon.

~~~
ffrryuu
You just need 1 mole inside Intel. I've been to multiple large corps, there
are no secrets once you are in.

Plus, NSA has the capability to reverse engineer chips at the physical level.

~~~
ballard
Donning tinfoil hat, NSA is just one part of USG. USG is one of hundreds of
countries, zillions of criminal enterprises that would like to get intel's
private keys and μcode format.

Given that intel is a large company the odds favor one/more external actors
having access.

There's really no way to know without some sort of way for IDS to check μcode.
Never going to happen due to the blackbox nature of closed, proprietary
systems.

~~~
XorNot
Or we could all just realize that for the time and effort of trying to write a
backdoor into a general purpose CPU, which would need huge amounts of memory
to be remotely capable of keeping track of code execution and to correctly
make an OS remotely exploitable (you know, involving the network stack,
probably TCP/IP and other things) rather then just crashing it...that it
easier just to email someone an executable saying "I love you.exe" and wait
for them to run it.

This is looking through the microscope to determine whether a forest is on
fire.

~~~
ffrryuu
Denying the truth won't make the problem go away.

