3 ms·

There is substantial complexity being swept under the rug here. Interesting talk but I remain skeptical. Anyone got stats on how FPGA ecosystems have fared vs.

There is substantial complexity being swept under the rug here. Interesting talk but I remain skeptical. Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? From a cursory search it seems: 1. There are very few PMOD suppliers 2. They do extremely low volume. So low, in fact, it appears there is simply ~no demand. Therefore, good luck hiring and scaling a team that is familiar with this stuff on a budget. Especially since the half-life of the software tooling is probably 3-6 months and the majority of toolchains are still vendor-specific. Further, in terms of supply chain security, the plethora of suppliers for lower-end MCUs cannot be matched in lower-cost FPGA offerings, which rely heavily on specific vendors who cannot readily guarantee global availability. M-LVDS is an onboard high speed signalling standard whereas USB and ethernet are specifically designed for off-board connectivity (and have features like power distribution, dynamic topologies, etc.). They are apples and oranges. The notion of a baseboard for these things is so simple, why isn't there a FPGA+PMOD+baseboard PCB generation and fabrication webservice offered by Digilent? Because it's not that simple. PCB design is often largely constrained by non-electronic functional aspects such as form factor, thermals, mounting and assembly considerations. Having modules to just plug in is great for a quick test, but the second you actually want a product you have to consider the whole problem and that typically means multiple iterations of traditional PCBs for these reasons. Conclusion: The case is over-stated and the market has effectively rejected the current offerings.

g_p 5y ago
> Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply. The vendor-specific toolchains and supply chain security issues you point out are huge issues, and ones most people (even security experts) are a bit blind to. You can't verify the state of a programmer FPGA by inspection (at least not using normal techniques), so you can't easily verify the output of your bitstream compiler, which is the output of the complex design toolchain. The toolchain output and bitstream are probably encrypted (or heavily obfuscated at minimum), and this will make it near impossible to audit the component. I don't see how anyone can defend against a Solarwinds (i.e. Stuxnet style attack) in the long run, as a toolchain compromise could introduce arbitrary modification of the logic, and would be unlikely to be spotted, and very difficult to ever detect once in the field.
- pclmulqdq 5y ago
  Bitstream encryption is okay, but someone still has yet to make an FPGA that is truly secure. As far as I know, bitstream encryption on the Xilinx Ultrascale+ devices has been broken, so there isn't a lot of protection there against sophisticated actors.
  - g_p 5y ago
    I've not had much experience with modern allegedly "secure" FPGAs, but the scenario I see here is if your synthesis tools get compromised by a bad update (or another attack), they could add a little bit of "side logic" to every design. Solarwinds style. With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected. Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.

g_p 5y ago

> Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply. The vendor-specific toolchains and supply chain security issues you point out are huge issues, and ones most people (even security experts) are a bit blind to. You can't verify the state of a programmer FPGA by inspection (at least not using normal techniques), so you can't easily verify the output of your bitstream compiler, which is the output of the complex design toolchain. The toolchain output and bitstream are probably encrypted (or heavily obfuscated at minimum), and this will make it near impossible to audit the component. I don't see how anyone can defend against a Solarwinds (i.e. Stuxnet style attack) in the long run, as a toolchain compromise could introduce arbitrary modification of the logic, and would be unlikely to be spotted, and very difficult to ever detect once in the field.

pclmulqdq 5y ago
Bitstream encryption is okay, but someone still has yet to make an FPGA that is truly secure. As far as I know, bitstream encryption on the Xilinx Ultrascale+ devices has been broken, so there isn't a lot of protection there against sophisticated actors.
- g_p 5y ago
  I've not had much experience with modern allegedly "secure" FPGAs, but the scenario I see here is if your synthesis tools get compromised by a bad update (or another attack), they could add a little bit of "side logic" to every design. Solarwinds style. With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected. Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.