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.
On “I don't trust microcode” (2021)
31–40 of 56 posts
Re: On “I don't trust microcode” (2021)
#32Microcode 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.
Re: On “I don't trust microcode” (2021)
#33Re: On “I don't trust microcode” (2021)
#34I 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
Re: On “I don't trust microcode” (2021)
#35Re: On “I don't trust microcode” (2021)
#36Re: On “I don't trust microcode” (2021)
#37When 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.
> 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)
#38The 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.
Original microcode should be trusted equal to the rest of the chip.
Re: On “I don't trust microcode” (2021)
#39When 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)
#40I 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.