7 ms·
On “I don't trust microcode” (2021)
- slackfan 4y agoThe 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.
- mouse_ 4y agoCybersecurity and updates in general are mostly gaslighting. Not entirely, just mostly. Look to South Korea's banking situation for a flanderized example.
- bruce343434 4y agoWhat if your software is vulnerable to log4j? Only a matter of time before your app gets portscanned.
- zabzonk 4y agomy bad - misread
- gruez 4y ago>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.
- zabzonk 4y agook, i misread, will delete my comment - except i can't
- DethNinja 4y agoThere 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.
- pjmlp 4y agoSame applies to CPUs without microcode due to hardware design bugs.
- temptemptemp111 4y ago[dead]
- noorkersz 4y agowe 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
- gruez 4y agoThat's already a lost cause considering how hard it is to inspect the die (ie. the physical transistors) itself.
- User23 4y agoIt 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.
- gruez 4y ago>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.
- User23 4y agoAbsolutely. 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.
- NoToP 4y agoElectrons are a ponzi scheme. The more you look into it the more it's all empty space.
- cwzwarich 4y agoI 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.
- monocasa 4y agoOn 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.
- rzzzt 4y agoCan opcodes be diverted to enter SMM instead of what they were supposed to be doing?
- monocasa 4y agoI 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/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html https://www.intel.com/content/www/us/en/developer/articles/t...
- bitwize 4y agoMicrocode 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.
- chipsa 4y ago@kens has an explanation on his blog of microcode (from an Intel CPU): http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html http://www.righto.com/2022/11/how-8086-processors-microcode-...
- twisteriffic 4y ago> not microcoded Still microcoded, just not updatable. https://news.ycombinator.com/item?id=21428905 https://news.ycombinator.com/item?id=21428905
- monocasa 4y agoSo 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.
- chacham15 4y agoWhen 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.
- deleted 4y ago[deleted]
- muricula 4y agoThey'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/ http://www.inertiawar.com/microcode/
- 1letterunixname 4y agoThey 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-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/ https://arstechnica.com/gadgets/2020/10/in-a-first-researche... https://ieeeaccess.ieee.org/featured-articles/reverseengineering_intel_microcode/ https://ieeeaccess.ieee.org/featured-articles/reverseenginee... https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tree/main/intel-ucode https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... https://github.com/platomav/CPUMicrocodes 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.
- monocasa 4y ago
- wmf 4y agoThe 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.
- ignoramous 4y agoI am surprised you say so when chip makers (ex: Intel and Qualcomm; https://news.ycombinator.com/item?id=34085635 https://news.ycombinator.com/item?id=34085635) run entire OSes with higher privileges completely out of view and without any documentation?
- wmf 4y agoThat'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.
- deleted 4y ago[deleted]
- ShredKazoo 4y agoPlease educate us. Can you at least provide a link that justifies your view?
- amstan 4y agoReminds 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.
- Lt_Riza_Hawkeye 4y agoI 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
- phkahler 4y agoWhat 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.
- aYsY4dDQ2NrcNzA 4y agoThat’s a fun idea.
- deleted 4y ago[deleted]
- brokenmachine 4y agoAn interesting suggestion, if rather fanciful. So we are to trust our entire security to implausible what if scenarios?
- phkahler 4y ago>> 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.
- shrubble 4y agoThe 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).
- bo1024 4y agoThe 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.
- ip26 4y agoYou could say that about the entire CPU. Original microcode should be trusted equal to the rest of the chip.
- bo1024 4y agoYes, agree.
- detaro 4y agoThe 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.
- olliej 4y agoOk, very simple question: why do you trust the closed source vhdl/verilog/whatever but not the closed source microcode?
- 1letterunixname 4y agoA processor will boot without microcode updates, it will just be old ones without fixes. They're not persistent, by design.