5 ms·

> Back to square one. It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against th

> Back to square one. It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against that design to check for backdoors?

progre 6y ago
Is this chip open hardware? I didn't see that in the article but maybe you have other sources... In that case, you would still need is a electron scanning microscope and a known good reference to verify with.
nsajko 6y ago
> It's an open source processor, right? The term open source was used in the article, but did they mean that in an accurate sense, or was it just empty marketing? Also, I can't find the source after a short search. > Could the chip be compared against that design to check for backdoors? Don't know, but I'm sure much expertise, man-hours and expensive equipment would be necessary. Maybe prohibitively so.
tyingq 6y ago
Not sure how you would practically do that. You could thwart all that with a microcode layer anyway. I think the closest you're going to get to "verifiably secure" is an FPGA based core.
- MaxBarraclough 6y ago
  > Not sure how you would practically do that. The idea would be to somehow scan the design of the chip, presumably using an electron microscope as progre said, and compare it against the design's netlist. This isn't something I know much about, so perhaps it's not at all practical, but at least in principle this should be possible for chips with open designs. > You could thwart all that with a microcode layer anyway. 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. > I think the closest you're going to get to "verifiably secure" is an FPGA based core. I agree that's the most practical solution.
  - 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).
pabs3 6y ago
Check out bunnie's talk on supply chain security: https://www.bunniestudios.com/blog/?p=5519 https://www.bunniestudios.com/blog/?p=5519

> Back to square one. It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against that design to check for backdoors?

progre 6y ago

Is this chip open hardware? I didn't see that in the article but maybe you have other sources... In that case, you would still need is a electron scanning microscope and a known good reference to verify with.

nsajko 6y ago

> It's an open source processor, right? The term open source was used in the article, but did they mean that in an accurate sense, or was it just empty marketing? Also, I can't find the source after a short search. > Could the chip be compared against that design to check for backdoors? Don't know, but I'm sure much expertise, man-hours and expensive equipment would be necessary. Maybe prohibitively so.

tyingq 6y ago

Not sure how you would practically do that. You could thwart all that with a microcode layer anyway. I think the closest you're going to get to "verifiably secure" is an FPGA based core.

MaxBarraclough 6y ago
> Not sure how you would practically do that. The idea would be to somehow scan the design of the chip, presumably using an electron microscope as progre said, and compare it against the design's netlist. This isn't something I know much about, so perhaps it's not at all practical, but at least in principle this should be possible for chips with open designs. > You could thwart all that with a microcode layer anyway. 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. > I think the closest you're going to get to "verifiably secure" is an FPGA based core. I agree that's the most practical solution.
- 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).

pabs3 6y ago

Check out bunnie's talk on supply chain security: https://www.bunniestudios.com/blog/?p=5519 https://www.bunniestudios.com/blog/?p=5519