3 ms·

I see what you're saying now, that the microcode would also need to be published and studied, and it would also be necessary to ensure the delivered microcode m

I see what you're saying now, that the microcode would also need to be published and studied, and it would also be necessary to ensure the delivered microcode matched the published microcode. I thought you were saying that the use of microcode would complicate verification of the hardware. If it's open hardware, I presume they'll publish the microcode.

tyingq 6y ago
"I thought you were saying that the use of microcode would complicate verification of the hardware." I do think that microcode opens up the possibility of subtle injections to follow code/hardware paths you might not easily predict. A really good talk on reverse engineering an ISA implementation: https://youtu.be/KrksBdWcZgQ https://youtu.be/KrksBdWcZgQ
- MaxBarraclough 6y ago
  Agreed, this is an issue with complexity more generally, but microcode seems like a particularly important case. As far as I can tell from the software world though, it's pretty rare for anyone to try this kind of thing. When their software is Free and Open Source, some companies put telemetry in there (e.g. Visual Studio Code), but it's very rare for there to be anything this malicious hidden away in publicly viewable code. The Linux world has collectively agreed to trust SELinux, for instance, despite that it originates from the NSA.
gnramires 6y ago
You need a way to scan the microcode as well, which you can't practically do physically (e.g. even with an x-ray scanner), at least when not some kind of circuit ROM. So you need to scan the microcode; this demands care I think. Whatever you are reading could be reporting itself incorrectly, if you were to read it through software (that is itself influenced by the microcode). One solution would be to have a hardware module, a verified function that dumps the microcode and cannot be significantly influenced by the microcode itself. Another issue could be program obfuscation, where you hide behavior inside your program. Since microcode is quite small, I guess the risk is also small. As a curiosity, as far as I know Cryptographic theory at this point hasn't proved whether efficient white-box obfuscation is possible! (specially for the case of obfuscating cryptographic keys), but there are some proposed methods that generate very large obfuscated programs, and there are several manual techniques (by experienced programmers) that make it difficult to decode to figure out function (we don't know if this could be generalized and automated).
- monocasa 6y ago
  You can generally pretty easily see the bits of a mask rom as easily as you can see any other gates.

tyingq 6y ago

"I thought you were saying that the use of microcode would complicate verification of the hardware." I do think that microcode opens up the possibility of subtle injections to follow code/hardware paths you might not easily predict. A really good talk on reverse engineering an ISA implementation: https://youtu.be/KrksBdWcZgQ https://youtu.be/KrksBdWcZgQ

MaxBarraclough 6y ago
Agreed, this is an issue with complexity more generally, but microcode seems like a particularly important case. As far as I can tell from the software world though, it's pretty rare for anyone to try this kind of thing. When their software is Free and Open Source, some companies put telemetry in there (e.g. Visual Studio Code), but it's very rare for there to be anything this malicious hidden away in publicly viewable code. The Linux world has collectively agreed to trust SELinux, for instance, despite that it originates from the NSA.

gnramires 6y ago

You need a way to scan the microcode as well, which you can't practically do physically (e.g. even with an x-ray scanner), at least when not some kind of circuit ROM. So you need to scan the microcode; this demands care I think. Whatever you are reading could be reporting itself incorrectly, if you were to read it through software (that is itself influenced by the microcode). One solution would be to have a hardware module, a verified function that dumps the microcode and cannot be significantly influenced by the microcode itself. Another issue could be program obfuscation, where you hide behavior inside your program. Since microcode is quite small, I guess the risk is also small. As a curiosity, as far as I know Cryptographic theory at this point hasn't proved whether efficient white-box obfuscation is possible! (specially for the case of obfuscating cryptographic keys), but there are some proposed methods that generate very large obfuscated programs, and there are several manual techniques (by experienced programmers) that make it difficult to decode to figure out function (we don't know if this could be generalized and automated).

monocasa 6y ago
You can generally pretty easily see the bits of a mask rom as easily as you can see any other gates.