Hacker News Reader

The thing is, the PCIe EP on the FPGAs uses the general purpose SerDes that are routed to the PCIe controller in the bitstream. So if you were to load a different malicious bitstream (which is admittedly a challenge in it's own regard) You could turn the FPGA into a malicious PCIe device.

View on HN

Is the concern the idea that as FPGA fabric is included in more devices, some hypervisor escape is going to present this as additional attack surface?

Otherwise if it's configfs you're root on the system and unless it's integrated peripherals you plan to attack you probably have finer grained hardware context to imply physical access... which seems to minimize the farther reaching, generalizable concerns?

If physical (evil maid attacks) are not in scope I fail to see the concern. To turn the FPGA into a malicious device you would have to gain root access to the system hosting it. So by the time the attacker is able to gain the ability to program the device, there is little need to even make it malicious. One could argue that it adds persistence vector to malware, except that the device likely will get reprogrammed over and over during normal operation. If malware authors wanted persistence they would likely target firmwares of random flash roms on chipsets and commodity PCIe cards that are less likely to be re-programmed. Lastly, the only other valid concern possibly more dangerous than root access is perhaps a remote attacker programming a bitstream to completely fry the FPGA faster than the power regulators can react and thus killing an expensive chip. That one is concerning.

Shouldn't that be solvable by extending mandatory access control frameworks to the IOMMU?

Reply on news.ycombinator.com