Hacker News Reader

Comment by amelius | Hacker News Reader

> The chip foundry wouldn't know what the FPGA will be used for, and where the proverbial "privilege bit" will end up being laid out on the chip, which mitigates against Privilege Escalation hardware backdoors. Exposure is limited to DoS attacks being planted into the silicon during FPGA fabrication, which yields a significantly improved level of assurance (i.e., the computer may stop working altogether, but can't betray its owner to an adversary while pretending to operate correctly).

I suppose in theory the FPGA could contain a hidden CPU that has full read/write access to the FPGA program.

Further, if the system becomes popular and more FPGAs need to be produced for the same system or the next generation, then the foundry has additional information and they can make a good guess of where the privilege bit will be. Even simpler, they could program an FPGA with the code and figure it out manually.

View on HN

I suppose in theory the FPGA could contain a hidden CPU that has full read/write access to the FPGA program.

All of them do at this point. It isn't hidden.

You can't buy a large FPGA without an ARM core in it. The ARM cores all have an opaque signed blob running in EL3 that you can't replace. This isn't a soft core on the fabric; it's dedicated silicon. And it has access to the ICAP (internal configuration access port) on Xilinx devices, and the equivalent on all the other manufacturers.

What is it for?

The ARM Core?

It's usually used for anything software you need and the FPGA gets used for any domain specific circuit for signal processing and what not in hardware. The ARM core usually runs a linux or any other OS and is used for communication with other devices. It's just able to run at a higher frequency than most soft-cores, because it's a fully integrated and optimized circuit. So in theory that's a nice thing and gives you more space for custom circuits on the programmable logic part.

PS: The latest polarfire chips from Microchip use a RISC-V CPU. Since AMD has announced the microblaze-v (their proprietary soft-core CPU with RISC-V ISA), I assume they soon (tm) will release their zynq range with dedicated RISC-V in near future, too. But even if it's an open instruction set, it's still a closed source CPU

I'm not sure what you mean. The biggest FPGAs do not have hard processors built in. Those which do feature hard cores usually advertise it specifically.

See Xilinx's UltraScale+ Kintex and Virtex series, both able to have more logic elements than the Zynq MP equivalents https://docs.amd.com/v/u/en-US/ds890-ultrascale-overview

yea op (the person you're responding to) is wearing a tinfoil hat. source i work for AMD (formerly xilinx). there are about a billion reasons it isn't true (starting with we'd charge you more money for the IP instead of hiding it) and ending with ultrascales are sold to DoD and there's very little room for shenanigans there.

I think backdooring the RAM would be easier. Modern DRAM has lots of complicated features (e.g. link training, targeted refresh, on-die ECC). I don't know exactly how it's implemented, but that's plenty of complexity to provide cover for backdoors.

It should be possible to add something that watches for specific memory access patterns and provides arbitrary read/write capabilities when the correct pattern is detected. This could be used for privilege escalation from untrusted but sandboxed code, e.g. JavaScript. It could work with any CPU architecture or OS, because the arbitrary memory reads could be used to detect the correct place to write.

This would be less effective with DIMMs or other multi-chip memory modules, but RISC-V computers are usually small single-board computers that only have a single DRAM chip.

Could you encrypt the data you send to the RAM?

Yes, and hardware support for encrypted RAM already exists:

https://en.wikipedia.org/wiki/Trusted_execution_environment

However, this will never be perfectly secure against backdoored RAM in a multitasking environment, because the memory access patterns alone leak information. Additionally, I don't think any of these systems support authenticated encryption, which means you could do things like corrupt branch targets and hope to land on a big NOP slide you control.

This sort of thing is analogous to the "Thompson hack" [1], where a malicious compiler has a self-propagating backdoor. It never shows up in the source code, but self-injects into the binaries.

Thompson demonstrated this under controlled conditions. But realistically, the backdoor begins to approach AGI-level cunning to evade attempts at detection. It has to keep functioning and propagating as the hardware and software evolve, while still keeping a profile (size, execution time, etc.) low enough to continue evading detection.

Work like this that rebuilds modern computing on a completely different foundation, would seriously disrupt and complicate the use of this type of backdoor.

https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...

FFS - when a smart person designs something clever it "begins to approach AGI-level cunning"? AGI doesn't exist, at the moment it's purely mythical

I think they meant that a realistic attack would need to be an AGI, not that an AGI was built.

I wonder as well whether it wouldn't just be easier to snoop I/O and somehow exfiltrate the data. (This would be completely impractical for dragnet surveillance, of course – but I'm sure if a state actor knew that some organization was using this technique to avoid surveillance, _and_ was using a predictable software setup...)

> I suppose in theory the FPGA could contain a hidden CPU that has full read/write access to the FPGA program.

Even if it did, it would be exceptionally difficult for that CPU to identify which registers/gates on the FPGA were being used to implement which components of the soft CPU. The layout isn't fixed; there's no consistent mapping of hardware LUTs/FFs to synthesized functionality.

Even if the mapping changes, the network (graph of logic gates) will locally be similar. So a subgraph matching algorithm might be all that is needed.

That would you mean you connect your hidden CPU to essentially every wire inside the FPGA. Trivial to detect, and extremely expensive, and probably even impossible considering timing model.

There's no need for such complexity. FPGAs read their programming from an i2c eeprom/flash when they boot, the hidden CPU just has to sniff that bus to get the entire bitstream and know the mapping.

And then you know that mapping. That still means you will need to connect to arbitrary wires. If you have the mapping but you aren't connected to the wire you want to disrupt or sniff then tough luck you can't do anything.

Theoretically what you could do is MITM the bitstream, upload it to a server. Resynthesize, place and route with your sniff wires connected and write that back flash. But now you have to hide a radio, and either force a restart or hope a restart will happen.

It's certainly non-trivial to put a hidden CPU in a FPGA that has full read/write access. The wire configuration inside the FPGA will be different for every design loaded into, hell even for the same design the place and router will do different things. So to what will you connect your hidden CPU?

Without having thought it through fully I feel like the classic "trusting trust" attack could work at the fpga/bitstream level.

For a nation state the most useful thing would be a "kill bit" where you can broadcast some signal or key and disable all your enemy's computers. That's fairly easy to do in an FPGA - the signal would be detected by the serdes block(s) and the kill bit could just kill the power or clock or some other vital part of the chip.

No, it's the opposite. The FPGA makes it much harder to hide a trojan in the silicon. If the LUTs were biased, it would be detected fairly quickly. A dedicated circuit with an RF interface would be equally obvious in terms of chip usage and power draw.

I didn't say anything about modifying the LUTs or adding RF interfaces, I don't know where you got that from.

How would the in-field FPGA receive the broadcast in your scenario?

Even better, a logical fuse that would make recovery impossibly expensive and timely.

> For a nation state the most useful thing would be a "kill bit" where you can broadcast some signal or key and disable all your enemy's computers.

CNE is generally considered to be far more valuable than CNA. First of all keep in mind that all genuinely sensitive systems are air gapped, so you can't effectively broadcast a signal to them.

Second, CNA is a one-off; after the attack you will typically lose access. CNE access on the other hand can persist for years or even decades, and will be beneficial in both "cold" scenarios for political and economic maneuvers, and closer to a flashpoint. CNA, on the other hand, is usually only relevant when a conflict is turning hot.

Reply on news.ycombinator.com