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.
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.
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.
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.
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...
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.
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.
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.
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.
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.)
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.
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
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.
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.
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.
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 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).
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.
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.
55 comments
[ 14.8 ms ] story [ 221 ms ] threadThe article is unequivocally pro microcode. The title is him replying to people who don't trust microcode, so it's a rebuttal.
if we cannot inspect the content of the microcode updates in the context of the architecture's schematics then it won't be trusted
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.
On non/less-microcoded CPU, this same functionality would be achieved by a higher-level firmware/OS update.
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.
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...
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.
Still microcoded, just not updatable.
https://news.ycombinator.com/item?id=21428905
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.
Thanks for a very succinct summary of a question I've pondered for a bit too.
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.
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.
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.)
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.
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
> 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?
So we are to trust our entire security to implausible what if scenarios?
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.
Original microcode should be trusted equal to the rest of the chip.