There are no blobs I'm aware of anywhere that are actually running in the system.
The STM32s have a small boot "ROM" burned into a write-protected region of flash but I have it jumpered so I boot from main user flash, not the bootloader.
I did a quick silicon overview of them (just out of curiosity... they came new from Digikey so I have no reason to believe they're fishy).
The 12-port PHYs are a fused-down version of a switch chip so there is a MIPS core on there, but to the best of my knowledge in the switch SKU it doesn't actually run (e.g. its RAM bus is NC and the IO power rail is grounded).
The FPGA is completely programmed from the bitstream I control. Tampering with a random resold FPGA to add some kind of backdoor is extraordinarily difficult and unlikely, it's the kind of thing you would see done as a targeted attack rather than just dumping FPGAs into the secondary market and hoping that a juicy intelligence target buys them rather than some guy tinkering around with open source projects.
And, if I ever get the slightest hint that there is something fishy about silicon I bought from a sketchy overseas source, I'm gonna take it into the lab at work and go to town. I do semiconductor reverse engineering at my day job and am the absolute last person anyone should try to sneak backdoored chips past. It's going to end up getting dissected inside a SEM and turn into an awesome talk at REcon or something.
While it would be slightly annoying to have my side projects disrupted, having a living breathing nation-state silicon backdoor show up in my lab would be a dream come true. I'd be ordering as many more chips as I could from the same seller and instrumenting it in every way possible, practicing on non-backdoored chips to make absolutely certain I didn't damage any of the spicy ones while studying the altered circuits, etc.
I've wargamed how I'd backdoor an FPGA even given the ability to make a completely new mask set from a fork of the original CAD files, and it's really difficult.
You'd either have to add an enormous amount of logic or have extremely detailed a priori knowledge of exactly what someone was going to use it for (down to what functions each pin was being used for). Making it meet the original factory performance and timing specs would be immensely difficult.
The best idea I had was that you could add some logic inside the transceiver IP that would understand common networking line codes and then bridge packets with certain magic header values over to an ICAP or something, so that you could enable an unauthenticated partial reconfig over IP channel.
But when you have lots of different line codes out there and don't know the bus width or configuration the user is going to have now suddenly you have to implement half a dozen different PCSes inside your fork of the GTY IP without changing the layout enough to fail timing or change the bump map enough to be visible to someone looking at the substrate or...
Small stuff like adding bypasses to bitstream encryption I could see, but nothing that would be a major risk to something like this.
Oh for sure, I was posting in response to the OP concerned about open source supply chain attacks. I think your work here is great and makes loads of sense specifically because of security. I trust an open supply chain a lot more than I do a closed one.
