Hacker News Reader

Comment by wjakob | Hacker News Reader

I'm curious as to how AWS plans to prevent users from generating malicious FPGA bitcode that physically damages the FPGA itself and/or the host machine over PCI Express. The possibility of instantiating arbitrary logic gates in the cloud seems very dangerous.

View on HN

Great question! I checked in with the team and this is what they told me:

"The developer FPGA code is enclaved inside AWS FPGA Shell, to prevent malicious FPGA code from damaging the hardware and to provide the necessary protection for PCI Express and the host machine. The pin assignment of the FPGA is controlled by AWS."

And

"AWS infrastructure monitors the thermals as well and the F1 hardware was designed to sustain high power consumption to enable developers to utilize the maximal available FPGA resources and frequency."

I spent a few minutes poking around their project scripts, and it looks like that the design file you upload back to EC2 is a post-routed design checkpoint, which is an interesting choice... I'll bet that they are doing partial reconfiguration with the I/O ring as the "static" layer.

My very limited FPGA experience is taht the development tools give warnings about strange loops, but it sounds like it's easy enough to blow one up accidentally: https://electronics.stackexchange.com/questions/293915/vhdl-...

I have not read the whole FPGA HDK guide yet, but, I doubt amazon will give the designer access to pins on FPGA; they would give access to interfaces or IO blocks which connect to the pins

your design sits inside a wrapper with access to IO blocks.

inside the FPGA logic, you cannot do electrical damage, no matter how hard you try.

Thermal damage may be possible, but they probably have monitoring that will shut down your logic if overheating is detected.

You could have a lot of combinational logic dependent on floating/high-Z inputs, which is not good for CMOS circuitry.

What's so bad about high-Z inputs? Designing around a floating input is the same as designing around an undefined variable. Bad design but you can't "hurt" the hardware.

An undefined variable is an abstract construct. You can model a floating input in as being analogous to an undefined variable and the model will fit reality most of the time, but the underlying reality is still governed by the complexities of physics, with potential for the model to break down.

Damage is probably more of a risk for an external I/O, but it's still a possibility for an internal I/O. Probably more of a certainty with a malicious programmer.

Who's going to be the first person to design an on-die switched capacitor voltage multiplier, using parasitic capacitance between gates as the energy storage, and use it drive an internal high impedance input to a damaging level?

The only tristate buffers in modern FPGAs are on the pins. There's no way to leave inputs floating internally.

Z logic or tri-state logic are not real in FPGAs, they are chains of AND OR logic

so basically you cannot burn FPGA by making a short-circuit

A floating pin on a CMOS device is absolutely real.

inside the FPGA logic, you cannot do electrical damage, no matter how hard you try.

I'd be a little worried about people making ring oscillators and driving them from the fastest possible output from a DCM. That used to be a hazard, not sure if it still would be at the UltraScale level of play.

Or creating a configurable DCM or PLL and then setting it up with illegal values at runtime, when the synthesis tool won't notice...

You break it, you buy it? AWS has your credit card on file ;)

I hope your credit card limits are high, digikey has them starting at $7k and going up quickly from there.

Reply on news.ycombinator.com