[Lramseyer]

You're attaching your design to the Mac layer inside the FPGA, not to the IO pins, so it's the PIPE interface or something similar that you would need to communicate with. And yes, you can bypass the PCIe or Ethernet controller on various models of FPGAs.

[krupan]

Sorry, but it's still not clear what exact attack scenario you are envisioning. I have PC with a motherboard that has a CPU and am FPGA. I load my custom nefarious PCIe core onto the FPGA that bypasses the built in PCIe core. Now what? What is my PCIe core actually connected to?

[davrosthedalek]

To make the FPGA actually useful, it probably is connected to the PCIe lanes. Since PCIe isn't really a bus anymore, it's not clear what is possible, but I believe a PCIe device principally can access all of memory (via DMA or similar)? Maybe an IOMMU can protect that, but I would be very surprised if bugs couldn't be found especially if you can make your PCIe device speak not-quite-right PCIe.

And since it's near impossible to validate FPGA firmware functionality by the kernel, rights to send bitstreams to the FPGA is essentially equivalent of root on DOM0.

[krupan]

Any PCIe device you plug into your computer has the same potential to do something nefarious. We already have problems where no two PCIe implementations interpret the spec the exact same way and they all have bugs. What you are hypothesizing isn't anything new.

[davrosthedalek]

The difference is that you don't need physical access anymore. You can convert a "good" device into a "bad" device via software.

[krupan]

This thread started with "gaping security hole" and I'm still not seeing that. Yes, if someone has a PCIe design that can exploit the root complex of the host, and if they have a way to remotely deploy it to an FPGA through this new kernel interface, then yes, that's an interesting new attack. Those are some big ifs though, I think.