On “I don't trust microcode” (2021) | Hacker News Reader

On “I don't trust microcode” (2021)

patrick.georgi.family

75 pointsignoramous51 comments

When I read this, I expected there to be some discussion about the chain of custody, verification of the signature of microcode updates, or possible injection attacks, but none of that is mentioned here. I think those are the real reasons that people are afraid of microcode...even in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified.

They're signed and I believe encrypted by Intel. The CPU will fail to apply a microcode update whose signature fails validation. Here's the best public discussion about the format of microcode updates I know of offhand: http://www.inertiawar.com/microcode/

They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files.

Intel microcode update secret key revealed

https://arstechnica.com/gadgets/2020/10/in-a-first-researche...

https://ieeeaccess.ieee.org/featured-articles/reverseenginee...

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://github.com/platomav/CPUMicrocodes

It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.

For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked.

Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode

You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them.

> in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified

How is this different than any other piece of software?

Reproducible builds.

Microcode is far more low level than "to exponentiate, multiply repeatedly". More like, take an instruction such as ADD AX, BX. I'm using a 16-bit example to keep things simple. That might decode into micro-ops as follows:

1. set the ALU input 0 to take input from register AX

2. set the ALU input 1 to take input from register BX

3. set the ALU output to register AX

4. tell the ALU to ADD

And I bet I oversimplified it and got it wrong.

Each micro-op tells the CPU which control lines to turn on and off to activate the registers, ALU, memory bus, etc. Historically it lived on ROM for Intel parts, but that's changed in recent decades. User-programmable microcode was a thing; microcode extensions allowed the Xerox Alto's CPU to function as a proto-GPU, with operations like fast line draws and BitBlt, allowing the Smalltalk UI to be drawn MUCH faster than you'd expect a mid-70s minicomputer to do. Even in the micro era, the DEC Alpha and the Nintendo 64's GPU both had user-loadable microcode. Intel and AMD chips don't allow this; their microcode updates have to be vendor-signed.

But yeah, if you don't trust microcode, don't run an Intel CPU. Stick with God's own perfect CPU, the 6502... its control logic is hardwired, not microcoded. That's part of why it was so cheap and so fast.

@kens has an explanation on his blog of microcode (from an Intel CPU): http://www.righto.com/2022/11/how-8086-processors-microcode-...

> not microcoded

Still microcoded, just not updatable.

https://news.ycombinator.com/item?id=21428905

So I've reflected on my previous statements there, and have come to the conclusion that the 6502's PLA isn't microcode or a compression format for a microcode ROM. The big piece it's missing is the microinstruction address counter. There was a T state counter which was tripping me up, but having played with the visual 6502, the T state counter really isn't a full microinstruction addr counter. The PLA is really more logically like individual CAMs for each of the control lines looking at the instruction register and the T states. So the PLA really is more an encoding of random logic than a microcode ROM. They end up being really close concepts though.

A great case of 'that guy that inhabited this same body a few years ago was a fucking idiot and needs to learn to shut his mouth'. I'm sure the person to inhabitant this body in a few years will say the same about me.

> So the PLA really is more an encoding of random logic than a microcode ROM.

Thanks for a very succinct summary of a question I've pondered for a bit too.

I was looking for an example that works with middle-school knowledge of computation but that isn't so trivial as to be meaningless. Implementing exponentiation in terms of multiplication seemed to fit the bill.

I could have tried to put in a rough approximation of the rdmsr state machine, but people would have rightfully tuned out in the second sentence.

Look for Bit Slice Design by Donnamaie E. White or the "Mick & Brick" bitslice book. Both take you through simple but non-trivial microcode use cases.

Nintendo 64’s RSP (Reality Signal Processor) was effectively a vector-optimized MIPS CPU, so its “microcode” was really just MIPS assembly. The “micro” aspect of RSP microcode came from the 4KB Instruction Memory and 4KB Data Memory that the RSP had direct access to.

The RSP was not a GPU, but it did process display lists before handing them off to the RDP (Reality Display Processor). RSP microcode was used for audio processing, video decoding, display list transform & lighting, as well as other more general processing tasks such as terrain generation.

> Stick with God's own perfect CPU, the 6502

Except that if you want to buy one today, you'd likely get a 65c02... which is fully microcoded (in the sense of having a microcode LUT, rather than a PLA.)

Reminds me of Ben Eater's 'Write a program from scratch' series, which he beings by coding up the 65c02 unit with an EPROM and an IO device: https://www.youtube.com/watch?v=yl8vPW5hydQ&list=PLowKtXNTBy...

I don’t work on x86 CPUs, but it’s my understanding that most “microcode updates” change the values of HW registers (or “chicken bits”) to disable problematic CPU optimizations rather than changing the literal microcode expansions of instructions.

On non/less-microcoded CPU, this same functionality would be achieved by a higher-level firmware/OS update.

On the x86 microcode we've been able to take a look at publicly (Goldmont and K10), the update files have in fact been primarily what we'd think of as code rather than just flipping chicken bits. There exist x86 chicken bits, but those tend to be more or less regular (albeit undocumented) MSR fields that can be flipped early in boot by updated BIOSes, or later if, say, a kernel patch to do so pops up.

The microcode update files instead seem to be installed in a little SRAM memory next to microcode ROM with a little CAM that matches on the microinstruction address in ROM and instead loads from SRAM. You basically get a half dozen to a dozen or so overrides for individual microinstruction words containing three or four micro instructions each and some control flow information.

Can opcodes be diverted to enter SMM instead of what they were supposed to be doing?

I don't see why not assuming that the opcode decoded to a ucode fetch in the first place, but I don't have that exact information in front of me to say 100% sure. I'd be shocked though if that wasn't possible.

Around your question though, on modernish Intel another mode exists that executes "XuCode" out of relatively normal RAM that kind of ends up looking like a restricted x86 subset to implement very complex x86 instructions. My understanding is that SGX enclave enter/exit is mainly implemented in XuCode. https://www.intel.com/content/www/us/en/developer/articles/t...

I begrudgingly trust microcode. The point isn't whether or not I do trust microcode, the point is I shouldn't have to - there's no reason for it to be so secretive

What if the main use of microcode is to provide certain customers custom instructions that the rest of us don't get. Perhaps the instructions themselves hint at algorithms that are not publicly known. That's not a threat to us, just secret instructions that can not be discovered.

That’s a fun idea.

An interesting suggestion, if rather fanciful.

So we are to trust our entire security to implausible what if scenarios?

>> An interesting suggestion, if rather fanciful.

It has been shown that government agencies were ahead of public research in areas of (specifically) cryptography in the past, so it makes sense that they would still be ahead today (that is one of their goals too I think). There have also been instructions in processors that didn't make a lot of sense at the time, though I don't recall a specific example or what it was speculated to be for.

The only thing I think is fanciful is this being the primary reason to have microcoded instructions in the first place. I wouldn't be surprised at all if certain customers had access to special instructions via microcode updates.

The article argues that one should trust microcode updates at least as much as the original microcode. Okay. But why would you trust microcode? It's closed source software running at the base layer of privilege and you have very little idea what it's doing or whether it's correct.

You could say that about the entire CPU.

Original microcode should be trusted equal to the rest of the chip.

Yes, agree.

The same logic applies to everything about the CPU though. That parts of it features are implemented in microcode instead of dedicated circuitry makes 0 difference for trust or not, so singling out microcode when not talking about updates is kinda odd.

Ok, very simple question: why do you trust the closed source vhdl/verilog/whatever but not the closed source microcode?

The Zilog Z8000 series, a 16-bit follow-on to the Z80, did not have any microcode in it, which meant it had less transistors than would otherwise be needed (17,500 vs 29,000 on the 8086, for example).

A processor will boot without microcode updates, it will just be old ones without fixes. They're not persistent, by design.

my bad - misread

>and if you are not going to trust microcode, what else are you not going to trust - logic gates, transistors, electrons?

The article is unequivocally pro microcode. The title is him replying to people who don't trust microcode, so it's a rebuttal.

ok, i misread, will delete my comment - except i can't

There are good reasons to not trust microcode. For example, a certain instruction chain can be made to trigger backdoors on the CPU and allow direct memory access for attackers. Catching this might be rather hard, though definitely not impossible.

Same applies to CPUs without microcode due to hardware design bugs.

we will distrust that which we cannot inspect.

if we cannot inspect the content of the microcode updates in the context of the architecture's schematics then it won't be trusted

That's already a lost cause considering how hard it is to inspect the die (ie. the physical transistors) itself.

It looks like a used SEM can be had for the highish five figures on eBay. Someone who was good at YouTube and other social media could probably justify the expense. Of course there could be unintended consequences of having viral videos showing hardware backdoors in popular electronic devices.

>It looks like a used SEM can be had for the highish five figures on eBay

What's the resolution on those like? Also, keep in mind that there's a lot more work to physically inspecting the CPU than just buying a SEM off ebay. You'd also need chemicals/equipment to etch through the different layers, as well the expertise to pull everything off.

Absolutely. And it's not as if the work of popularizing and profiting from that equipment and expertise is trivial either. Nevertheless, I reckon there's an opportunity there.

Electrons are a ponzi scheme. The more you look into it the more it's all empty space.

The whole pop culture around open source firmware and Coreboot is a disaster based on posturing and misinformation. It's like an infosec version of anti-vaxxing. Unfortunately, educating people about specific facts won't help because they'll just move on to complaining about something else like Pluton.

I am surprised you say so when chip makers (ex: Intel and Qualcomm; https://news.ycombinator.com/item?id=34085635) run entire OSes with higher privileges completely out of view and without any documentation?

That's a legitimate problem but it mostly isn't being discussed or addressed rationally. People keep pitching Coreboot as the solution to all these problems when it isn't.

Please educate us. Can you at least provide a link that justifies your view?

Reminds me of that libreboot that targetted a very specific rk3288 chromebook (out of the 8 available) even through the original coreboot was blobless on all of them.

The something or other axiom: Updates to most software have been inevitably harmful to any original user of that software. That goes for programs, that goes for microcode.

Cybersecurity and updates in general are mostly gaslighting. Not entirely, just mostly. Look to South Korea's banking situation for a flanderized example.

What if your software is vulnerable to log4j? Only a matter of time before your app gets portscanned.

Reply on news.ycombinator.com