A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
contrib.andrew.cmu.edu
A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
1–10 of 59 posts
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#2It’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.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#3Wow, I am starting to read all your reading material that you have put up.
It's really what I have always wanted to do and it's more than that because you are using FPGAs. I am from India and I want to help you in any way I can because I also have wanted to go on this journey. It's just amazing I wish you all the blessings.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#4hey this is the same guy who did some work for running osx on qemu/kvm. https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#5While 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.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#6This is very, very cool. I've been thinking for a while that a fully self-hosted RISC-V machine is sorely needed. The biggest limiting factor at the moment actually seems to be finding an FPGA board which has enough RAM on board. The target board here has 512 megabytes, I think - but FPGA toolchains are much happier with several gigabytes to play with.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#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 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.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#8> 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.
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.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#9While 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.
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.
Re: A trustworthy, free (libre), Linux capable, self-hosting 64bit RISC-V computer
#10> 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. 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.