Live data from Hacker News

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

patrick.georgi.family

31–40 of 56 posts

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

#31
post #29

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?

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

#32
post #20
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…

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.

Look for Bit Slice Design by Donnamaie E. White or the "Mick & Brick" bitslice book. Both take you through simple but non-trivial microcode use cases.

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

#34

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.

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

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

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

#37

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.

You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them.

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

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

#38
post #36

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.

You could say that about the entire CPU.

Original microcode should be trusted equal to the rest of the chip.

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

#39

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.

You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them. > 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?

Reproducible builds.

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

#40

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.

[deleted]
Post reply on HN