11–20 of 56 posts
my bad - misread
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
my bad - misread
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.
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.
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.
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.
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…
Earlier quoted context omitted.
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.
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 u…
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…
Still microcoded, just not updatable.
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…
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.