3 ms·

For one: it is almost entirely based on a non-free tool chain. They rely on a non-free Xilinx tool chain for the spartan 7 (XC7S50) FPGA which is the heart of

For one: it is almost entirely based on a non-free tool chain. They rely on a non-free Xilinx tool chain for the spartan 7 (XC7S50) FPGA which is the heart of the device. They do use an ice-40 (which has a free tool chain as well as a non-free tool chain) for the EC. Why didn’t they use another well supported FPGA with a free tool chain? Isn’t there an FPGA that has a free tool chain and matches or beats the performance of the spartan 7? It would certainly beat the security story of the spartan 7. Does the required non-free tool chain required to build the FPGA related code for the spartan 7 even run on non x86 CPUs these days? And how do we know that Xilinx doesn’t backdoor things when their tool chain is used? We don’t, and it’s weird to suggest that this is auditable or secure when compared with the rest of the system. Trusting trust is an old talk and the lessons still apply to FPGA toolchains, doesn’t it? I have two of these devices sitting on my desk and I am extremely frustrated that they chose a Xilinx Spartan 7 with a non-free tool chain. There is some progress to make a free tool chain for the Spartan 7, but they’re currently not using that work according to their git repo. Why not? I would guess because its a free software concern that isn’t very interesting and it’s just a lot of work. The Silicon Labs WF200 is also something that is questionable but it appears to be much more isolated than the spartan 7 FPGA. A novel approach might have been an SDR and another FPGA which could do Wi-Fi or another radio protocol. That is however obviously a lot of work, and I fully understand why this chip is isolated rather than fully redone from scratch. Still for such a device, I hope they eventually do tackle this problem too. If anyone can do it, it’s Sean and bunnie.

transpute 4y ago
I wonder if supply chain constraints prevented them from using an Artix-7 FPGA, for which a libre (reverse engineered) tool chain is available. Bunnie used an Artix-7 (XC7A35T) for the NeTV2 project, https://www.crowdsupply.com/alphamax/netv2 https://www.crowdsupply.com/alphamax/netv2 & https://www.bunniestudios.com/blog/?p=5018 https://www.bunniestudios.com/blog/?p=5018 > LiteX produces a design that uses about 20% of an XC7A50 FPGA with a runtime of about 10 minutes, whereas Vivado produces a design that consumes 85% of the same FPGA with a runtime of about 30-45 minutes. An early Precursor blog, https://www.crowdsupply.com/sutajio-kosagi/precursor/updates/evaluating-our-hardware-security https://www.crowdsupply.com/sutajio-kosagi/precursor/updates... > Precursor uses the Xilinx 7-series of FPGAs for its trusted root. This series of FPGAs is perhaps one of the most extensively studied from a security perspective; dozens of papers have been published about its architecture and vulnerabilities. As a result, its key stores have been reverse engineered and analyzed down to the transistor level ... its fuse boxes and encryption engine have been analyzed down to the gate level and there have been no findings so far reporting special access modes for law enforcement, undocumented shadow key stores, or other bugs that could lead to fully remote exploits or back doors.
- throwaway654329 4y ago
  It’s a good question - the analysis seems to ignore the need for non-free software to properly build the FPGA bitstream files from source. We have no way to know the Xilinx tools are safe. None of those papers address the tool chain question AFAIK. Additionally, it is difficult to know if a user has downloaded the real Xilinx software tool chain; the git repo ( https://github.com/betrusted-io/betrusted-soc https://github.com/betrusted-io/betrusted-soc ) from has no verification step for step 7. There is a public key and a hash, they could include this in the repo and at least it would make a targeted attack a little more difficult. Additionally they could use a git sub module for step 6 and have a better risc-v supply chain security story. It seems trivial to fix that detail, so I am sure it will be fixed if they’re alerted. These setup steps are trivial security issues, simple to fix, and possibly only theoretically an issue for a targeted attack. What isn’t theoretical is that the we cannot trust the non-free Xilinx tool chain as we can’t see the sources, so we don’t know that they’re not currently doing something bad (bugs or backdoors) or won’t later be doing something we don’t want. Frustrating! Related: https://news.ycombinator.com/item?id=32187651 https://news.ycombinator.com/item?id=32187651

transpute 4y ago

I wonder if supply chain constraints prevented them from using an Artix-7 FPGA, for which a libre (reverse engineered) tool chain is available. Bunnie used an Artix-7 (XC7A35T) for the NeTV2 project, https://www.crowdsupply.com/alphamax/netv2 https://www.crowdsupply.com/alphamax/netv2 & https://www.bunniestudios.com/blog/?p=5018 https://www.bunniestudios.com/blog/?p=5018 > LiteX produces a design that uses about 20% of an XC7A50 FPGA with a runtime of about 10 minutes, whereas Vivado produces a design that consumes 85% of the same FPGA with a runtime of about 30-45 minutes. An early Precursor blog, https://www.crowdsupply.com/sutajio-kosagi/precursor/updates/evaluating-our-hardware-security https://www.crowdsupply.com/sutajio-kosagi/precursor/updates... > Precursor uses the Xilinx 7-series of FPGAs for its trusted root. This series of FPGAs is perhaps one of the most extensively studied from a security perspective; dozens of papers have been published about its architecture and vulnerabilities. As a result, its key stores have been reverse engineered and analyzed down to the transistor level ... its fuse boxes and encryption engine have been analyzed down to the gate level and there have been no findings so far reporting special access modes for law enforcement, undocumented shadow key stores, or other bugs that could lead to fully remote exploits or back doors.

throwaway654329 4y ago
It’s a good question - the analysis seems to ignore the need for non-free software to properly build the FPGA bitstream files from source. We have no way to know the Xilinx tools are safe. None of those papers address the tool chain question AFAIK. Additionally, it is difficult to know if a user has downloaded the real Xilinx software tool chain; the git repo ( https://github.com/betrusted-io/betrusted-soc https://github.com/betrusted-io/betrusted-soc ) from has no verification step for step 7. There is a public key and a hash, they could include this in the repo and at least it would make a targeted attack a little more difficult. Additionally they could use a git sub module for step 6 and have a better risc-v supply chain security story. It seems trivial to fix that detail, so I am sure it will be fixed if they’re alerted. These setup steps are trivial security issues, simple to fix, and possibly only theoretically an issue for a targeted attack. What isn’t theoretical is that the we cannot trust the non-free Xilinx tool chain as we can’t see the sources, so we don’t know that they’re not currently doing something bad (bugs or backdoors) or won’t later be doing something we don’t want. Frustrating! Related: https://news.ycombinator.com/item?id=32187651 https://news.ycombinator.com/item?id=32187651