Hacker News Reader

Comment by cwzwarich | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com