3 ms·

> I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one

by nsajko 6y ago

> I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one on your chip. You're missing the fact that microcode lies between the hardware and the user-supplied machine code. Thus hardware+microcode is what has to be verified.

MaxBarraclough 6y ago
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.
Taniwha 6y ago
This is a risc chip, it's unlikely there's any microcode at all - I know of no RISC-V chip that has microcode. What there will be is a 0-stage boot ROM -it's not microcode, just RISC-V code -essentially the code that knows how to get from the first instruction after reset up to and including the loading of u-boot (or whatever) - if you're interested in how open a system is ask to see that code, and all the code that runs in m-mode (probably u-boot-spl and opensbi both of which are open source)
- monocasa 6y ago
  There's typically plenty of preboot code that is executed before the the architectural reset vector. Also, complex RISC cores will generally have a distinction between architectural instructions and micro instructions, sometimes using a mask ROM for the translation.

by nsajko 6y ago

MaxBarraclough 6y ago

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.

Taniwha 6y ago

This is a risc chip, it's unlikely there's any microcode at all - I know of no RISC-V chip that has microcode. What there will be is a 0-stage boot ROM -it's not microcode, just RISC-V code -essentially the code that knows how to get from the first instruction after reset up to and including the loading of u-boot (or whatever) - if you're interested in how open a system is ask to see that code, and all the code that runs in m-mode (probably u-boot-spl and opensbi both of which are open source)

monocasa 6y ago
There's typically plenty of preboot code that is executed before the the architectural reset vector. Also, complex RISC cores will generally have a distinction between architectural instructions and micro instructions, sometimes using a mask ROM for the translation.