Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

contrib.andrew.cmu.edu

Post reply on HN
Print view View original

21–30 of 59 posts

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#21

Post by glitchc »

rwmj wrote: post #15
amelius wrote: post #7

> 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.

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.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#22

Post by ooterness »

amelius wrote: post #7

> 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 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_...

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#23

Post by greggsy »

rwmj wrote: post #15
amelius wrote: post #7

> 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.

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

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#24

Post by musicale »

RobotToaster wrote: post #12
shrubble wrote: post #9

Earlier quoted context omitted.

People used 50Mhz SPARC systems to do real work, and the peripherals were all a lot slower (10mbps Ethernet, slower SCSI drives) with less and slower RAM. But it might take a week to compile everything you wanted, I agree; of course there is always cross-compiling as well.

That was before everything became a snap package in a docker image.

> That was before everything became a snap package in a docker image.

A modern app should consist of dozens of of docker images in k8s on remote cloud infrastructure, all running "serverless" microservices in optimized python*, connected via REST* APIs to a javascript front-end and/or electron "desktop" app, with extensive telemetry and analytics subsystems connected to a prometheus/grafana dashboard.

That is ignoring the ML/LLM components, of course.

If all of this is running reliably, and the network isn't broken again, then you may be able to share notepad pages between your laptop and smartphone.

*possibly golang/protobufs if your name happens to be google and if pytorch and tensorflow haven't been invented yet

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#25

Post by rowanG077 »

amelius wrote: post #7

> 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'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?

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#26

Post by rowanG077 »

amelius wrote: post #10
duskwuff wrote: post #8

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. 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.

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#28

Post by musicale »

kwhitefoot wrote: post #18
bitcompost wrote: post #11

Earlier quoted context omitted.

Oh I believe in theory a 50Mhz CPU is capable of doing almost everything I need, but it just lacks the software optimized for it. I think a week to compile everything is too optimistic.

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

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#29

Post by mntmn »

I did something similar in 2022, also with LiteX, but not self-hosting because it used a Kintex-7 FPGA which at least at the time required Vivado for the actual place-and-route. It did result in a open gateware laptop running Linux and Xorg, though (thanks to Linux-on-LiteX-VexRiscV): https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer

#30

Post by tredre3 »

rowanG077 wrote: post #26
amelius wrote: post #10

Earlier quoted context omitted.

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.
Post reply on HN