
An introduction to reverse-engineering x86 microcode and writing it - sohkamyung
https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask
======
userbinator
The paper itself is here, if you'd rather not sit through an hour-long video:
[http://syssec.rub.de/media/emma/veroeffentlichungen/2017/08/...](http://syssec.rub.de/media/emma/veroeffentlichungen/2017/08/16/usenix17-microcode.pdf)

AMD microarchitecture exploration seems to have progressed quite a lot farther
than Intel in general -- Google "9C5A203A" for some more interesting
reading...

~~~
white-flame
It's just a 30 minute video at 2x play speed. :)

~~~
quotemstr
Where's the playback speed control? I didn't see it.

~~~
slezyr
It's html5 video, press right mouse button over it.

~~~
quotemstr
Oh, awesome. I didn't realize that browsers had client-side support for
playback speed control these days.

------
quotemstr
I've always thought that it's a shame that CPU vendors haven't opened up
microcode programming to the public. To extend a silly graphics metaphor: it's
as if, right now, CPUs ran Vulkan, but we could only program them with Unity.

As the speakers in this talk point out, open microcode would allow extending
the CPU with brand-new capabilities, including not only high-performance
instrumentation frameworks, but also, I think, nearly-free ASAN-like and CFG-
like runtime safety checks.

Is security a reason not to open the microcode architecture? I don't think so.
I know this talk happened at CCC, but I don't see the security consequences of
open microcode being severe: if you're in a position to install a microcode
update, you've already won.*

Backward compatibility? Sure. Microcode can change generation-to-generation,
or even stepping-to-stepping. Public microcode programs would have to be
written with the understanding that no stability is guaranteed. But you can
still get a lot of useful work done that way --- for example, people write
Linux kernel drivers all the time.

Trade secrets? Eh. Does it really matter whether a processor has 32 or 64
internal temporary registers? I'm not sure what secrets proprietary microcode
might protect against an adversary that has a dedicated chip design team and
electron microscopes.

So, yeah, this talk represents impressive work, but none of this work should
be necessary. Then again, if wishes were horses, beggars would ride. We can't
even get Intel to ship a processor without the damn management engine.

* Granted, microcode backdoors have the virtue of being subtle and easy to hide. This paragraph doesn't apply if microcode updates let you break the processor's internal security model, but it sounds like, from the talk, that microcode obeys security invariants.

~~~
Const-me
Converting an abstraction layer into a public API is expensive.

Besides obvious documentation, tools and dev.support costs, also compatibility
cost. Currently Intel/AMD can change the microarchitecture however they see
fit, potentially even between revisions, as long as the instruction set stay
stable.

~~~
userbinator
_Currently Intel /AMD can change the microarchitecture however they see fit,
potentially even between revisions, as long as the instruction set stay
stable._

Changing the microarchitecture itself is not trivial either, and you can bet
that they've got it all documented internally along with tools and whatever
else. They could just open it up, as in post everything on their website for
download --- they don't have to provide "support". The only real reason they
don't is because there are things in there that they don't want the world to
know.

~~~
Const-me
> Changing the microarchitecture itself is not trivial either

Major changing is not trivial. However I can see how they can implement minor
tweaks between revisions that don’t affect their main interface (i.e. AMD64
instruction set + extensions) but do affect microcode.

> you can bet that they've got it all documented internally

I’ve worked in a couple of large US software companies. I won’t point fingers
but the internal documentation I’ve worked with wasn’t OK. The only exceptions
is when the company provided a public API. When that was the case, they
allocated resources (developer’s time, plus sometimes a technical writer
position) and did the job.

> along with tools and whatever else

Legal issues are likely. E.g. GPL-licensed code is fine in an internal tool,
but if you want to distribute it, you have to also distribute the source code
of everything else that’s linked. Sometimes you don’t want to, other times you
just can’t (if it links to a commercial library you’ve bought).

> because there are things in there that they don't want the world to know

I don’t eliminate the possibility but I don’t think that’s likely. As you see,
there’re pragmatic reasons (i.e. money) why they aren’t doing that.

The good thing is, if anyone (Intel, AMD, I dunno, Apple, Qualcomm) will do
that, and it will indeed deliver a great value to the users (such as free
ASAN), the rest of them will do the same really fast, because competition.

------
madez
Recently here on Hacker News I had a short discussion with Steve Klabnik about
JavaScript and WebAssembly among other things.[0] My point is that to execute
randomly downloaded code is realistically impossible to secure, practically
used to deliver malware and usually used against the interests of the user of
the computer. If I can infer from Steve's stance the opinion of Mozilla, then
it's sad to see that the only big browser developer organization I had hopes
in simply waves these problems away and keeps on making JavaScript and
WebAssembly more usable and widespread. It's disheartening to see that.

The connection to this talk is that they demo triggering a backdoor hidden in
microcode by executing some WebAssembly code in an up-to-date FireFox.

[0]
[https://news.ycombinator.com/item?id=15981178](https://news.ycombinator.com/item?id=15981178)

~~~
jcranmer
On a von Neumann architecture, there is no actual distinction between code and
data. Every CPU architecture in widespread use is a von Neumann architecture
(GPUs, it should be noted generally aren't von Neumann). What this means is
that loading data from unsecure, untrusted sources is potentially the same as
executing code. In practice, this is actually very often the case--a buffer
overflow trivially turns data into code.

With that in mind, what realistically is possible to do, over than to declare
that everything can only be read as plain text (and hope there's no
exploitable bugs in font rendering of system fonts)?

~~~
madez
There is a huge difference from the security perspective between rendering a
static HTML site and executing JavaScript. That theoretically they might be
close has no practical meaning, and insisting on it may paralyse us into doing
nothing. Securing font rendering or HTML rendering is achievable. I suggest
replacing the C code by code written in a language with stronger static
verification, like Rust.

Also, JavaScript and WebAssembly (the latest starting with this talk) are
actively used for unauthorized access to computers. It's not like I'm pointing
out theoretical attack possibilities. This makes the matter more urgent.

~~~
jcranmer
What about JS is so odious? That it's Turing complete? Well, so is XSLT, yet
you don't seem uptight about people implementing it.

JS does provide some very valid use-cases, and two of them that come to mind
are interactivity and displaying static data that has no neat representation
in HTML (e.g., Mathjax and d3.js for charting).

My point is that JS is far from the only massive, complex, potentially
security-laden hole in a modern web browser. Audio/video codecs are
notoriously complex, and font rendering also has this nasty habit of causing
kernel crashes on Windows. These have been used for active exploits. The way
you achieve security is you have to look at the risks and work out ways to
mitigate them. There are ways to be quite secure even allowing JS execution.

~~~
pygy_
The addition of the NX bit to CPUs blurs the line between Von Neuman and
Harvard architectures.

Giving an attacker a JIT makes it easier for them to lay out memory with the
NX bit set to zero (executable memory) that they can later jump into.

Return-oriented programming can still be used to hijack a program that whose
executable parts are locked down at runtime, having a JIT just makes things
easier.

------
white-flame
Given that the microscope inspection saw the individual bits in the microcode
tables, I wonder how possible it would be to visually extract crypto keys
baked into the processor for newer models. I doubt they'd be in a nice orderly
addressed ROM area like this, but they still have to be hardcoded somewhere.

~~~
userbinator
_I wonder how possible it would be to visually extract crypto keys baked into
the processor for newer models_

AFAIK the Intel ones use public-key encryption[1], so you would not really
gain anything. They obviously thought of this.

[1] [http://inertiawar.com/microcode/](http://inertiawar.com/microcode/) \-
2048-bit RSA too, so not really breakable in the near future either.

~~~
solotronics
I wonder if there will be a point that machine learning algorithms can hack
better than humans? Already they can play certain games and find solutions
that seem alien to us. Perhaps this is already occuring?

------
rft
Author here, in case you have any questions.

~~~
pfalcon
If you can influence that, please make the PDF slides available on the CCC
page. Thanks.

------
stmw
This is really excellent, thanks for sharing. So much remains hidden in
today's x86 systems.

