41–50 of 59 posts
It’s really quite amazing to login a linux shell on an orangecrab FPGA running a RISV-V softcore, built using an open source toolchain. That was impossible not so long ago! At best you’d have something like Xilinx PetaLinux and all their proprietary junk.
A tiny iCE40 LP1K will fit SERV (and even QERV) no prob.
It's amazing how small a fully compliant RISC-V implementation can be.
While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.
> I can't even imagine the pain of building stuff like GCC on 60Mhz CPU Some of us remember what that sort of thing was like, not so very long ago...
Previously that had taken about 2 hours (Quadra with MPW), and I did clean builds only when absolutely necessary.
Truly painful was trying to write large programs in Apple (UCSD) Pascal on a 1 MHz 6502.
> 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…
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.
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.
> 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…
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.
Earlier quoted context omitted.
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.
> 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…
> 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…
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.
> 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…
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…
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…
What is it for?
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