An introduction to reverse-engineering x86 microcode and writing it

https://media.ccc.de/v/34c3-9058-everything_you_want_to_know_about_x86_microcode_but_might_have_been_afraid_to_ask

by sohkamyung • 9 years ago

197 69 9 years ago

media.ccc.de

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/...

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

white-flame2• 9 years ago

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

quotemstr4• 9 years ago

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

quotemstr4• 9 years ago

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.

jws• 9 years ago

I wonder about robustness. Can the microcode physically destroy the CPU? Consider driving a bus line both high and low simultaneously from two sources. That puts transistors which ordinarily spurt out a little current to overcome capacitance into a continuous maximum current situation. Compared to maximum toggle rate in normal operation, (50% duty cycle for a transistor, exponentially decaying current when on), I’ll estimate this will easily average four times the current.

The development cycle could be littered with dead processors, but worse for Intel, if a widely used microcode has a very infrequent chip stressing flaw it will manifest as “Intel chips aren’t reliable.”

sannee• 9 years ago

I don't think that tri-state logic is used in ICs anymore (?).

EDIT: http://vswww.kaist.ac.kr/ENGLISH/old_lecture/ee878-2002/lect...

It probably does not imply that the chip is indestructible through microcode though.

convolvatron• 9 years ago

maybe just support? a long time ago, when microcoded architectures were the default, i did some work at that level. without having access to the processor design itself it was pretty rough going. lots of back and forth, trial and error, cycle counting. there really isn't any intermediate abstraction layer you can define.

and how much are you really going to enable? some funny bit ops? some explicitly interleaved fetch and computation? its pretty cool to try to understand things, but is it worth it for Intel? alot of stuff seems to baked in hardware too...pretty sure the cache coherency protocol isn't on the table...maybe some different concurrency primitives?

bogomipz3• 9 years ago

" a long time ago, when microcoded architectures were the default,..."

They are default the now though. As far as I know hardwired control logic wasn't used for very long before people moved to using microcode. Maybe I am misunderstanding that part of your comment?

Const-me2• 9 years ago

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.

userbinator5• 9 years ago

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.

tomxor2• 9 years ago

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.*

Soft flashed roms must be cryptographically signed anyway... the main danger is surely in making various types of timing attacks or side-channel attacks substantially easier to derive, usually those attacks are inferred with great effort. The argument of security through obscurity is more complex compared to higher level software, it's not purely about finding bugs and refining implementation.

tomxor2• 9 years ago

... uh, I guess I was right? :P (in light of recent events)

mschuster912• 9 years ago

As the speakers in this talk point out, open microcode would allow extending the CPU with brand-new capabilities,

Exactly this is why CPU vendors won't do anything in that regard. They don't want people to have a way to avoid upgrading the hardware by buying a new processor.

marcosdumay4• 9 years ago

People upgrade CPUs mostly because of cache size, core count, IO speed, and core speed. Only the last one can improve by hacking microcode, and only marginally.

white-flame2• 9 years ago

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.

madez12• 9 years ago

There are techniques to prevent reading stored data in chips. Smartcards often have some of those protections.

marcosdumay4• 9 years ago

Good luck protecting against offline reading with a microscope. The only defense is that this thing is expensive.

userbinator5• 9 years ago

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/ - 2048-bit RSA too, so not really breakable in the near future either.

solotronics• 9 years ago

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?

rft3• 9 years ago

As was already pointed out, any protection scheme would most likely use asymetric crypto, so you can only dump the public key anyway. However there is a more pressing problem, that you would even have if symetric crypto was used: In order to extract the key you would need to know how it is encoded, which you only know once you know the plaintext of the microcode (which requires the encryption key to read the microcode updates). You run into a chicken-egg problem.

Without the processor oracle, it would have been hard to impossible to start guessing the semantics of bitstrings. Also the physical ROM bits are not in the same order as the bits the CPU actually excutes during runtime. The mapping function is non trivial and we do not fully understand it yet. Finding this function required knowing what valid, plaintext microcode looks like so we could match the bitstrings from the ROM to it.

madez12• 9 years ago

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

jcranmer2• 9 years ago

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)?

quotemstr4• 9 years ago

What is "code" anyway except instructions? The Harvard-Von-Neumann distinction is really a continuum. Even today's computers draw important distinctions between data and code: for example, we have separate data and instruction caches, and Linux has special caching behavior for PROT_EXEC pages.

(The latter is an annoyance, BTW: there's no reason to treat Java bytecode, say, differently from PROT_EXEC pages. Executable protection should have nothing to do with active or inactive list membership.)

madez12• 9 years ago

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.

TheAceOfHearts• 9 years ago

If I recall correctly, WASM separates code and data, along with a bunch of other security features.

afuchs• 9 years ago

[...] 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. [...]

This argument has been rehashed over and over again. Some of the mass appeal of the web, as a platform, is that random arbitrary code can be downloaded and run inside a sandbox. It appears that these web technologies will continue to be used regardless of any security implications.

If users demand something like JavaScript or WebAssembly, do you have an alternative proposal to satisfy them?

madez12• 9 years ago

Rehashing an argument does not make it wrong, and continuing doing so is still important if it's valid and not considered accordingly.

Users don't demand JavaScript nor WebAssembly, some developers do. Users want to easily discover new programs/games/whatever. If they were presented those equally easy and convenient in another form, they wouldn't even care.

Those developers that demand JavaScript and WebAssembly have mostly interests that go against the interests of the users. The developers might want to hide parts of their code or underlying data from the user, or force presentation in a certain form (ads), or avoid the orderly way of delivering software through proven ways like distributions, possibly to achieve the former two goals.

Now, where does Mozilla stand in this conflict? I realize they don't stand where I thought they would stand.

I want the web, but without random drive-by code execution. Code must be delivered by other, more accounted for ways.

drvdevd2• 9 years ago

Sorry if this is a dead point that’s already been discussed but: if the code is sandboxed then what is the difference between arbitrary WebAssembly and arbitrary JavaScript other than speed? It all comes down to instructions executing in the same sandbox doesn’t it? From a security perspective what does this actually change? Is it just that there’s a greater capacity for obfuscation?

madez12• 9 years ago

It makes the use-case for this type of code deployment wider, it's more effective at what it's already used for, and it's also less auditable.

These are three reasons why developing and supporting WebAssembly is finally against the interest of the users.

The harder, less efficient and cumbersome this type of drive-by code deployment is, the less attractive and used it'll be.

Also, sandboxing helps only until it doesn't. It's a futile task, especially when we don't have complete control of the hardware, which we don't, because the chip developers don't tell us complete specificiations and functionality.

taxreform• 9 years ago

From my experiences of reversing Windows x86 applications, I don't think WebAssembly has a greater capacity for obfuscation. In fact, I think WebAssembly is less capable of obfuscating code than JavaScript.

It is because WASM does not allow self-modifying code, which is a highly effective obfuscation technique as it can hinder static analysis. On the other hand, JavaScript has eval among other things that can be used to dynamically craft and execute code during execution. I've never seen such JavaScript but it would be quite cumbersome to trace code within a call to eval within a call to eval, and so on. You might need to build a custom V8 to record strings passed to eval when reversing such code.

legulere• 9 years ago

My point is that to execute randomly downloaded code is realistically impossible to secure

This is absolutely not true if you have a MMU and something like a protection ring. In such an environment code by default can do nothing malicious. The only thing making it insecure in any way are the syscalls offered by the operating system.

rft3• 9 years ago

Author here: I chose WebAssembly, because it allowed for easy insertion of an instruction we understand perfectly and can backdoor. With more work we could have highjacked an instruction in the actual binary of Firefox and started the attack from there. WebAssembly simply gives primitives that allow for an easier attack (emitting of a specific instruction, chosing constants and predictive code generation). Not WebAssembly itself enabled the attack, it just made it easier.

Exploiting HTML or font rendering is more work, but as you still run known instructions in a known sequence processing known data the primitives are still there. The same can happen for anything that processes foreign data, be it script, video, images or just CSV.

madez12• 9 years ago

Let me first thank you for the incredibly important work of finding and documenting behaviour of hardware we use.

I see your point. However, if it's harder for the attacker, it is already a win. Also, this is just one example where JavaScript/WebAssembly are used to deliver/activate malware. There are many other examples.

Besides that, even if JavaScript/WebAssembly implementations were provably secure (which they aren't), I would be against them for the other reasons I described in other comments here.

marcosdumay4• 9 years ago

Logical sandboxing is a perfectly possible problem that can even be made correct by formal methods. Browsers don't use a proven correct implementation because testing are enough to get almost perfect already.

So, are your concerns about side channel attacks? Side channels are nothing more than undocumented (and sometimes unfixable) logical features. Opening the microcode for inspection and making it patchable will only reduce the number of undocumented features.

steveklabnik2• 9 years ago

If I can infer from Steve's stance the opinion of Mozilla

Please take my opinions as my own.

madez12• 9 years ago

Sorry for referencing you that way. I can't change it anymore. I could have pointed to decisions taken by Mozilla to explain my disappointment instead of extrapolating from your statements. Even if your view were exactly what I was criticizing Mozilla for (which I neither think, know nor assume), there was no need for that reference since my critique is not specific to a person. It's bad taste to point to a single person. On top of that, the inference wasn't well justified. I realize I handled that badly, and I learn from that. So, I actually thank you for pointing it out politely.

I don't mean to justify but rather to give context when I say that these discussion are not easy because there are lots of arguments and comments of varying degree of quality and emotional content, and contradicting voting. It's hard to represent an unpopular opinion. Still no justification whatsoever.

madez12• 9 years ago

If I can infer from Steve's stance the opinion of Mozilla

Mozilla's decisions speak for themselves. There is no need to reference individuals, and less so without very solid basis (which there wasn't).

rft3• 9 years ago

Author here, in case you have any questions.

pfalcon3• 9 years ago

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

stmw• 9 years ago

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

An introduction to reverse-engineering x86 microcode and writing it

Related Stories