3 ms·

In this new Intel microcode bug, Tavis writes: "We know something strange is happening, but how microcode works in modern systems is a closely guarded secret."

In this new Intel microcode bug, Tavis writes: "We know something strange is happening, but how microcode works in modern systems is a closely guarded secret." My question: How likely is it that this is an intentional bug door that was added into the microcode by Intel and its government partners? I don't know enough about microcode and CPU's to be able to answer this myself, so backed-up opinions welcome!

jsnell 3y ago
0%. This isn't how anyone would backdoor a CPU. An actual backdoor would be done via some instruction sequence that is basically impossible to trigger by accident and hard to detect even when triggered.
- fsflover 3y ago
  Can you give an example of such sequence? Is it really so easy to hide it given that the microcode can be decoded in principle, https://news.ycombinator.com/item?id=32145324 https://news.ycombinator.com/item?id=32145324? Why is hiding it in a "bug" a worse solution? Why you can't do both?
  - jsnell 3y ago
    Here's a couple of plausible ways. One is to make the condition for the backdoor trigger based on multiple (unlikely) instructions in sequence. This bug was triggered by a single instruction, so it would have been a pretty easy case for fuzzing. If you need a sequence of 10 specific instructions in a specific sequence, with no kind of observable side-effects for getting just the first 9 right so that nobody can do a guided search? That's not going to be found just by random chance. It doesn't matter what those instructions are, as long as they're not something that would get generated by real compilers on real programs. The other is to make it dependent on the data rather than just the static instructions. Like, what if you had the SHA1 acceleration instructions trigger a backdoor iff the output of the hash is a certain value? You could probably even arrange for the backdoor to get triggered from managed and sandboxed runtimes like Javascript, rather than needing to get the victim to run native code. And somebody triggering this by accident would be equivalent to a SHA1 preimage collision.
deleted 3y ago
[deleted]

jsnell 3y ago

0%. This isn't how anyone would backdoor a CPU. An actual backdoor would be done via some instruction sequence that is basically impossible to trigger by accident and hard to detect even when triggered.

fsflover 3y ago
Can you give an example of such sequence? Is it really so easy to hide it given that the microcode can be decoded in principle, https://news.ycombinator.com/item?id=32145324 https://news.ycombinator.com/item?id=32145324? Why is hiding it in a "bug" a worse solution? Why you can't do both?
- jsnell 3y ago
  Here's a couple of plausible ways. One is to make the condition for the backdoor trigger based on multiple (unlikely) instructions in sequence. This bug was triggered by a single instruction, so it would have been a pretty easy case for fuzzing. If you need a sequence of 10 specific instructions in a specific sequence, with no kind of observable side-effects for getting just the first 9 right so that nobody can do a guided search? That's not going to be found just by random chance. It doesn't matter what those instructions are, as long as they're not something that would get generated by real compilers on real programs. The other is to make it dependent on the data rather than just the static instructions. Like, what if you had the SHA1 acceleration instructions trigger a backdoor iff the output of the hash is a certain value? You could probably even arrange for the backdoor to get triggered from managed and sandboxed runtimes like Javascript, rather than needing to get the victim to run native code. And somebody triggering this by accident would be equivalent to a SHA1 preimage collision.

deleted 3y ago

[deleted]