IRC channel logs
2024-09-26.log
back to list of logs
<matrix_bridge><Lance R. Vick> Has anyone tried implementing FPGA gateware that boots and produces a seed from source? <aggi>ao486 project... hasn't got no known USB nor ethernet support; seabios and IDE boot are documented <matrix_bridge><Andrius Štikonas> Lance R. Vick: so basically hex0 implemented in FPGA? <matrix_bridge><Lance R. Vick> of course, then you have to actually compile the verilog... <matrix_bridge><Lance R. Vick> but would be at least one more implementation <aggi>in practice FPGA deployments to bootstrap x86 have little benefit, because the complete supply chain is proprietary and stuffed with vendor malice <matrix_bridge><Lance R. Vick> but there are open source fpga toolchains now <aggi>appreciated, nonetheless i have difficulties with the design rationale behind the software-engineering involved, that those toolchains rely upon <aggi>don't intend to be rude, as a sidenote, that touches the whole c++ and GNU toolchain on the software side, to compile all the GNU/GTK/... stuff <matrix_bridge><Lance R. Vick> Yeah its turtles all the way down. Who knows what toolchains make the CPUs we are using to bootstrap from? At the end of the day, you are trusting a CPU made by a factory somewhere that may or may not have backdoors, that could know about your use case in advance and tamper with it, or you get a device which is raw gates, and use an open toolchain to assemble those gates into the electron paths you... <matrix_bridge>... want at runtime, so the manufacturer in advance has no means to tamper with a particular high security use case. <lrvick>Ideally the FPGA path matches the same binaries/results that a traditional amd/intel cpu path gets and we continue to stack trust. <aggi>simple question, since i haven't played with VHDL/Verilog etc... <aggi>was there some deployment tooling which didn't need any c++? <aggi>such as, you could write Verilog/VHDL with vi-editor, and any other software to compile Verilog/VHDL and flashing was written in C? <aggi>to do such work at the terminal console? <aggi>or would i need an Eclipse IDE type of thing? <lrvick>it is all simple CLI tools now, of which the open implementations can get the same results as the proprietray toolchains now afaict, though more implementatinos would be ideal. <lrvick>you end up with the gateware seed, and then you have a totally alternative path to bootstrap that, gaining control of the CPU itself <aggi>i wouldn't believe it until i had not tried myself to deploy any free/open x86 SoC (such as ao486) myself <aggi>or any other SoC, even when it was some 16bit 6502/z80/tiny-risc whatever <lrvick>Plenty of open source architecture designs. Trouble is proving the chip in front of you actually implements one faithfully. <lrvick>today FPGAs with open toolchains are kind of the only solution that exists <lrvick>short of soldering together a primitive CPU yourself <lrvick>which friends have done, but, I don't have -that- much patience <aggi>well, much patience was required already, 30years since when i486 was introduced, to see some free/open SoC such as ao486 <aggi>which is too problematic for the tooling required to compile/deploy SeaBIOS (tcc-toolchain probably wouldn't suffice, hence the whole GNU binutils/gcc needed) <aggi>GNU toolchain is great, but i think it's problematic when relying upon it early in the whole bootstrapping path (too with hardware development utilities and BIOS stuff) <lrvick>Yeah it is non trivial. I full-source-bootstrapped qemu, seabios, and all required firmware last week to get to a bootable OS... that will now do it all over again and ideally get the same result <aggi>historically, i386 was bootstrapped from 16bit systems <aggi>those are the ones you could actually solder yourself onto breadboard; not saying anyone should, and it's not feasible nowadays, to re-confirm the transition from 16bit towards 32bit with a free/open supply chain <aggi>besides trust, it's the basis of the entire supply chain that raises concerns <lrvick>Well, you -could- breadboard a 16 bit CPU that can convert hex0 to a binary for another platform... <lrvick>getting seeds from handmade hardware would be pretty badass, and maybe doable <nikolar>realistically, you can breadboard the i386 too <aggi>realistically you had to re-implement the original IBM PC, which gives you a VT100 type of terminal <lrvick>bootstrapping some of these tools, could mean bootstrapping a slightly more modern CPU we can trust to bootstrap everything else <lrvick>we need to bootstrap hex0 with provably correct electron paths in the metal :D <lrvick>for my own threat model, and that of my clients, bootstrapping our entire distro from hex0 up on a wide diversity of hardware, and getting the same results, is good enough for me <lrvick>but it is a lot to coordinate and reason about. simple baremetal paths would be nice <lrvick>something like punchcards with verilog we can inspect on paper, fed into a hand-soldered verilog to bitstream converter hardwrare, that outputs a RISC-V core, microkernel, and hex0, that can kick off something like live-bootstrap <lrvick>This might be the only room in the world where I could type that and hit enter with a straight face. <aggi>i'll continue with tcc-toolchain system-integration, to avoid GNU toolchain <aggi>two weeks ago, the system-profile of ~500 ebuilds fully passed, no more binutils/gcc required at all <aggi>i required two weeks break, will review all the emerge logs, because i'll loose python/portage and autools/perl - hence have to re-integrate _everything_ to keep it self-hosting with tcc-toolchain <aggi>the re-integration _without_ perl/autotools and python/portage is alot of work, but it's highly benefitial to do it regardless <aggi>and it is not blocking some other task i will pick-up again: full support for linux-2.4 with tcc-toolchain <aggi>it is good gcc and binutils can be bootstrapped optionally (i re-confirmed it works, outside bootstrappeble and with gentoo-crossdev tooling instead) <aggi>tcc has a huge benefit: it's very fast, compile-times are almost irelevant in comparison to gcc, hence i can work much faster with much less fatigue while waiting <aggi>and it is a high priority, to keep gcc/binutils _optional_, and too keeping gentoo/python and perl/autotools optional <aggi>because, such toolchain and system-integration utilities are a huge burden <matrix_bridge><Andrius Štikonas> lrvick: well, going from userspace bootstrap to bootstrap on top of FW (BIOS/UEFI, etc...) is definitely doable and is only marginally harder <matrix_bridge><Andrius Štikonas> anything lower is far more labour intensive and / or involves making hardware, so not for everyone... <matrix_bridge><Andrius Štikonas> but former is just booting CPU from seed, rather than running seed on your existing OS <aggi>it's not marginal, because you would need to break a circular dependency, except if you closed both eyes to not see the issue there was <aggi>for ao486 there is SeaBIOS, yet for this you need gcc/binutils, which isn't bootstrapped yet <aggi>with anything more elaborate than 16bit you'll encounter such circular dependencies <aggi>with both, software and hardware development <aggi>i can live with it, but it's not marginal either <aggi>what is accomplished is elaborate trust, and that's good; a circular dependency however is bad and contradicts the criteria of bootstrapping <aggi>or, to rephrase this, you need utilities for bootstrapping which aren't bootstrapped at the time you need those <aggi>without 16bit system (both hardware and software), what you can accomplish then, is injecting a trustworthy seed into such circular dependency <aggi>the fact it is gcc/binutils itself involved (instead of tcc-toolchain "only"), is a tad bit more ironic even <oriansj>aggi: one could do a BIOS is M1 for some target CPU core and one would only need to implement a dozen BIOS calls. then it would just be a one time task to convert that to hex0 and ultimately the bootstrap ROM for 1 trusted hardware bootstrap. <matrix_bridge><Andrius Štikonas> Yes, FW is not bootstrapped but neither it is bootstrapped during userspace bootstrap <matrix_bridge><Andrius Štikonas> What I'm saying is only that removing kernel is not that hard <matrix_bridge><Andrius Štikonas> Removing FW or hardware from bootstrap seed is significantly harder