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

41–50 of 56 posts

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

#41

Post by detaro »

bo1024 wrote: 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.

The same logic applies to everything about the CPU though. That parts of it features are implemented in microcode instead of dedicated circuitry makes 0 difference for trust or not, so singling out microcode when not talking about updates is kinda odd.

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

#42

Post by aYsY4dDQ2NrcNzA »

phkahler wrote: post #34
Lt_Riza_Hawkeye wrote: post #33

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.

That’s a fun idea.

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

#43

Post by olliej »

bo1024 wrote: 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.

Ok, very simple question: why do you trust the closed source vhdl/verilog/whatever but not the closed source microcode?

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

#45

Post by wmf »

ignoramous wrote: post #31
wmf wrote: 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?

That's a legitimate problem but it mostly isn't being discussed or addressed rationally. People keep pitching Coreboot as the solution to all these problems when it isn't.

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

#46

Post by 1letterunixname »

muricula wrote: post #28
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/

They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files.

Intel microcode update secret key revealed

https://arstechnica.com/gadgets/2020/10/in-a-first-researche...

https://ieeeaccess.ieee.org/featured-articles/reverseenginee...

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://github.com/platomav/CPUMicrocodes

It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.

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

#47

Post by brokenmachine »

phkahler wrote: post #34
Lt_Riza_Hawkeye wrote: post #33

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.

An interesting suggestion, if rather fanciful.

So we are to trust our entire security to implausible what if scenarios?

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

#48

Post by monocasa »

1letterunixname wrote: post #46
muricula wrote: post #28

Earlier quoted context omitted.

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/

They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files. Intel microcode update secret key revealed https://arstechnica.com/gadgets/2020/10/in-a-first-researche... https://ieeeaccess.ieee.org/featured-articles/reverseenginee... ht…

For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked.

Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode

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

#49

Post by ShredKazoo »

wmf wrote: 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.

Please educate us. Can you at least provide a link that justifies your view?

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

#50

Post by [deleted] »

wmf wrote: post #45
ignoramous wrote: post #31

Earlier quoted context omitted.

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?

That's a legitimate problem but it mostly isn't being discussed or addressed rationally. People keep pitching Coreboot as the solution to all these problems when it isn't.

[deleted]
Post reply on HN