[HN Gopher] A trustworthy, free (libre), Linux capable, self-hos...
___________________________________________________________________
A trustworthy, free (libre), Linux capable, self-hosting 64bit
RISC-V computer
Author : caned
Score : 130 points
Date : 2024-05-18 15:53 UTC (7 hours ago)
(HTM) web link (www.contrib.andrew.cmu.edu)
(TXT) w3m dump (www.contrib.andrew.cmu.edu)
| buildbot wrote:
| 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.
| Guestmodinfo wrote:
| Wow, 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.
| dmarinus wrote:
| hey this is the same guy who did some work for running osx on
| qemu/kvm. https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
| bitcompost wrote:
| 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.
| shrubble wrote:
| 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.
| bitcompost wrote:
| 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.
| kwhitefoot wrote:
| 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.
| musicale wrote:
| 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
| RobotToaster wrote:
| That was before everything became a snap package in a docker
| image.
| musicale wrote:
| > 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
| sweetjuly wrote:
| You can definitely go considerably faster. A lot of these FOSS
| cores are either outright unoptimized or target ASICs and so
| end up performing very badly on FPGAs. A well designed core on
| a modern FPGA (not one of these bottom of the barrel low power
| Lattice parts) can definitely hit 250+ MHz with a much more
| powerful microarch. It's neither cheap nor easy which is why we
| tend not to see it in the hobby space. That, and better FPGAs
| tend not to have FOSS toolchains and so it doesn't quite meet
| the libre spirit.
|
| But, yes, even at 250MHz trying to run Chipyard on a softcore
| would certainly be an exercise in patience :)
| dwheeler wrote:
| At one time many of us dreamed of having a computer that could
| run as fast as 60MHz. The first computers I used ran around
| 1MHz. Compilation will take longer on a slower machine, but
| that really isn't a big deal. If the computer is reliable and
| the build scripts are correct, you can just let the process run
| over days or weeks. I've run many tasks in my life that took
| days or weeks. Cue "compiling": https://xkcd.com/303/
|
| The real problem is debugging. Debugging the process on a slow
| system can be unpleasant due to long turn-arounds. Historically
| the solution is to work in stages & be able to restart at
| different points (so you don't have to do the _whole_ process
| each time). That would work here too. In this case, there 's an
| additional option: you can debug the scripts on a much faster
| though less trustworthy system. Then, once it works, you can
| run it on the slower system.
| robinsonb5 wrote:
| This 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.
| amelius wrote:
| > 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.
| duskwuff wrote:
| > 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.
| amelius wrote:
| 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.
| rowanG077 wrote:
| 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.
| nxobject wrote:
| 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...)
| rwmj wrote:
| 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.
| glitchc wrote:
| 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.
| greggsy wrote:
| Even better, a logical fuse that would make recovery
| impossibly expensive and timely.
| admax88qqq wrote:
| Without having thought it through fully I feel like the classic
| "trusting trust" attack could work at the fpga/bitstream level.
| ooterness wrote:
| 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_...
| rowanG077 wrote:
| 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?
| ruslan wrote:
| I'm kind of going the same direction, but different route. My
| design is based on VexRiscv and all hardware is written in
| SpinalHDL. It does not run Linux yet because of limited SRAM
| (512KB) on my Karnix board, but it has Ethernet and HDMI. I have
| coded a CGA-like video adapter with HDMI interface that supports
| graphics (320x240x4) and text (80x30x16) modes with hardware
| assisted smooth scrolling. :)
|
| If someone is interested, here's a rather brief README:
| https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
|
| KiCAD project for the board: https://github.com/Fabmicro-
| LLC/Karnix_ASB-254
| musicale wrote:
| Rebuilding the system on itself and validating that the bitfile
| is the same is nice.
|
| I'm amazed that it could be rebuilt in 512MB (and in "only" 4.5
| hours on a ~65MHz CPU.) My experience with yosys (and vivado
| etc.) is that they seem to want many gigabytes.
|
| > A 65MHz Linux-capable CPU inevitably invokes memories of mid-
| 1990s Intel 486 and first-generation Pentium processors.
|
| 50-65MHz* and 512MB seems comparable to an early 1990s Unix
| workstation. Arguably better on the RAM side.
|
| *4.5 Mflops on double precision linpack for lowRISC/50MHz
| ranger_danger wrote:
| There's nothing free about FPGAs...
| mntmn wrote:
| 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...
___________________________________________________________________
(page generated 2024-05-18 23:00 UTC)