Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

patrick.georgi.family

Post reply on HN
Print view View original

21–30 of 56 posts

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

#21

Post by queezey »

bitwize wrote: post #15

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…

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.

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

#22

Post by derefr »

bitwize wrote: post #15

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…

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

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

#23

Post by gruez »

User23 wrote: post #17
gruez wrote: post #11

Earlier quoted context omitted.

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.

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

#24

Post by monocasa »

rzzzt wrote: post #18
monocasa wrote: post #13

Earlier quoted context omitted.

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…

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

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

#25

Post by monocasa »

twisteriffic wrote: post #19
bitwize wrote: post #15

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…

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

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

#26

Post by chacham15 »

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.

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

#27

Post by [deleted] »

chacham15 wrote: post #26

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.

[deleted]

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

#28

Post by muricula »

chacham15 wrote: post #26

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/

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

#29

Post by wmf »

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.

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

#30

Post by ignoramous »

derefr wrote: post #22
bitwize wrote: post #15

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…

> 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...
Post reply on HN