51–59 of 59 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 softwa…
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
Good overview at wikipedia - https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)
> 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 be…
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 por…
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
Earlier quoted context omitted.
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 por…
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
Earlier quoted context omitted.
I did valuable work on a 2 MHz Apple II with a 4 MHz Z80 add-on running CP/M that I used to write the documentation. The documentation part was just as fast forty years ago as it is now but assembling the code was glacially slow. The 6502 macro assembler running on the Apple too forty minutes to assemble code that filled an 8 k EPROM.
6502 assemblers are amazingly fast on more recent hardware. Something like 60-70ms to run a script to assemble and link an a version of msbasic (AppleSoft) on my old laptop. https://github.com/mist64/msbasic
> 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 be…
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…
Earlier quoted context omitted.
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…
Could you encrypt the data you send to the RAM?
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.