<stikonas>that said, I think we can still push that change <stikonas>Hagfish: fossy is slowly working on kernel <Hagfish>fossy: what are the requirements for the kernel, or at what point does it make sense to try building it and booting into it? <stikonas>only old patched kernel can be built with it but you can do that <Hagfish>and i guess it uses the shell of the host system <Hagfish>and that old patched kernel is enough to run the subsequent bootstrap steps? <stikonas>we are not using that much in terms of kernel <Hagfish>there's a nice sense of "dogfooding" if (some of) the bootstrapping process itself can run in a kernel that it compiled <Hagfish>it's like that expression that if you can escape earth's orbit, you are half way towards anywhere else in the universe <stikonas>well, we haven't solved the problem of bootstrap kernel... <stikonas>you can't do that from inside live-bootstrap <stikonas>you have to manually use M2-Planet on baremetal <stikonas>and then build some simple kernel that can support VFS and processes <Hagfish>yeah, starting the bootstrap is the "cheating" bit, like getting into orbit <Hagfish>m2-planet on baremetal is an incredible idea <Hagfish>is it possible to meaningfully test that in qemu? <stikonas>well, that wouldn't really be mroe trustworthy... <Hagfish>but it would prove that the steps work, which could be run on someone's actual bare metal <stikonas>maybe... But then again there is a question of hardware trust <Hagfish>yes, i don't think any CI process can really give confidence in that (especially not one hosted remotely) <Hagfish>the CI is still valuable though, of course <stikonas>you can have slightly different startings points, like asmg does... <Hagfish>i suspect that there will be more "false positives" than "true positives" when people run the bootstrap process on their own machines/kernels <Hagfish>i.e. we're not going to uncover any actual trusting-trust attacks, but people are going to need to debug the process of porting the bootstrap steps <stikonas>yeah, there isn't that much place for trusting-trust attack now... <stikonas>but also extremely hard to defend against <stikonas>pder: what is very strange is that we didn't have problems with bash 3.2.57, but I don't see any differences in source of psize.c or psize.sh between bash 3.2.57 and 5.1 <OriansJ>Hagfish: M2-Planet on baremetal is why cc-minimal.c exists; just set a few variables and it'll build for any target you want from any device to any other device. <OriansJ>Ultimately the only steps that require a kernel are after M2-Planet+mescc-tools and one could write a simple POSIX Kernel using the M2-Planet subset of C. <stikonas>it doesn't even have to be fill POSIX kernel... <Hagfish>the work to build up to gcc has been fantastic, and it sounds like the work to extend the bootstrapping chain downwards is going to be just as impressive <Hagfish>i think it wouldn't be clickbait to say "from bare metal" if the first steps are run without requiring a traditional kernel <Hagfish>the astute will ask "where did the first kernel come from?", and that's valid, but just reducing the size of that kernel gives some information about the costs to an attacker <Hagfish>they would have to include within that kernel a payload which can detect every possible kernel and compiler, in order to propagate itself into the compiled result of subsequent steps in the bootstrap ***mephista is now known as spicy_icecream
<fossy><stikonas> fossy: did you mention before that newer libtool would automatically work with autoreconf? <fossy>Hagfish: fwiw, qemu is untrusted <fossy>It is for development primarily <Hagfish>i guess what i was unsure about was whether qemu has a minimum level of complexity it requires of the kernel it boots, i.e. whether "M2-planet on bare metal" would be supported (for testing) on it ***ChanServ sets mode: +o rekado_
<pder>stikonas: for the bash checksum problem, should we just force PIPESIZE to 65536 in builtins/pipesize.h? <stikonas_>pder: that might be one solution, I'm still thinking what might be the cause <stikonas_>pder: so on the bad run, if I rerun psize.sh it returns correct PIPESIZE ***stikonas_ is now known as stikonas
<stikonas>could it somehow be because we run it with bash-mes <pder>maybe its the bash version in which psize.sh is running <stikonas>that's why I am thinking maybe it's worth building older bash first <pder>I didnt look closely at bash 3.2.57 and if it uses that same psize.sh script <stikonas>psize.sh uses traps, which I think were not working for me properly when I was writing helpers.sh <stikonas>pder: I've also been thiniking a bit about removing stuff, we probably want to have a better "package manager" later than helpers.sh <stikonas>maybe with DESTDIR like most normal distros do, so that we install somewhere else, then can checksum files, and maybe keep some "install manifest" <stikonas>otherwise it's getting harder to keep track of what is installed by what <stikonas>maybe we can do that at the same time as glibc migration... <pder>stikonas: another idea for bash-5.1 build is to do normal build and then rerun psize.sh on the new bash followed by make. <pder>ok, I will try that out. I plan to commit this on your gcc branch right before you disable bash-5.1 build <stikonas>yeah, that's fine, if you can fix it I can replace disable bash-5.1 with your commits <stikonas>pder: actually, I think the simplest solution might be to sed -i 's/sleep 3/sleep 3; sleep 3/' psize.sh ***civodul` is now known as civodul
<pder>I can try that, but why two sleep 3 commands? Wouldnt sleep 6 work? <pder>I pushed my change to gcc branch, if you'd like to see what I'm currently testing <pder>Note I also have my mktemp branch applied as well so we have mktemp <stikonas>pder: I'm not sure if that "| sleep 3" works properly <stikonas>it might be that an extra sleep 1 will work <pder>stikonas: I looked closer at psize.c and my understanding is that the code initializes buf with 128 spaces then creates a signal handler for SIGPIPE named sigpipe which is defined at the top. Then in the for loop it tries to write 128 byte chunks of buf to stdout forever or until it gets a SIGPIPE signal. <pder>thats why the output of psize.aux is piped to sleep so it will eventually trigger the signal <pder>so I dont think adding an additional sleep will do anything <pder>is that running psize.sh with bash-2.05b? <stikonas>when I cat that temporary file I still see 65 K in <stikonas>so I think sleep 1 helps with some race condition <pder>so the if [ -s "$TMPFILE ] must be failing <pder>hmm so the tmp file is 0 size when the "if -s" test is done but after sleeping it contains 65536? <stikonas>I think I like, putting some workaround in psize.sh slightly more, because then we don't have intermediate non-deterministic binaries <pder>thats understandable. just sleeping seems a little fragile- could we poll for the tmpfile to be greater than 0 size? <pder>or would sync fix the issue? <stikonas>otherwise polling would probably be a loop of sleeps anyway ***lukedashjr is now known as luke-jr
<stikonas>pder: so I think even inserting /after/bin/true makes it deterministic <stikonas>oh, I see, bash builtin true doesn't work but calling /after/bin/true from coreutils is sufficient <pder>interesting- maybe its easy to add sync from coreutils? <stikonas>so do we need to go for trouble of building sync? <pder>stikonas: I just tried adding sync to coreutils-5.0 pass2 and it was a trivial change- I think Ill rename my mktemp branch to coreutils and it will be all about adding mktemp and sync <stikonas>ok, running sync probably makes more sense <stikonas>I can merge your branch into mine if you want <pder>ok, I just pushed my changes to coreutils branch <fossy><stikonas> pder: I've also been thiniking a bit about removing stuff, we probably want to have a better "package manager" later than helpers.sh <fossy>hm, I am not so sure about thisn <fossy>but we need to think about the architecture of it very carefully, as it is a pretty abnormal use case for a package manager <fossy><stikonas> ok, running sync probably makes more sense <fossy>thats really odd given we are in an initramfs <fossy>thats why we are having issues in qemu! <fossy>cause theres no need for sync in initramfs but there is on disk <stikonas>well, by "package manager" I mean something that can install into DESTDIR instead of directly into system, so that then we can automatically checksum all files (it's getting harder to keep track of what is installed by make install), keep the list of files, and maybe have an option of easily removing all <stikonas>e.g. now we might be installing some files, let's say into /after/share/ then installing newer version of some updated version on top, which might have a slightly different set of files, some some files will be overwritten, but some old cruft might stay behind <OriansJ>stikonas: if guile can be built by TCC+musl; you could just leverage guix <fossy>OriansJ: but then we need to create a lot of guix packages <fossy>and I dont think either of us know guix packaging very well <bauen1>if you have perl, maybe gnu stow can do this job <stikonas>I was thinking of just extending bash a bit... <fossy>I was just coming back here to say haha <fossy>I think stow is a very good option <stikonas>just need to adjust it a bit to install into DESTDIR, add a function or two <stikonas>hmm, never heard of gnu stow, maybe worth taking a look <fossy>stikonas: but how do we manage the file list and the like <fossy>stow is basically you install to a prefix and it symlinks things to a more normal directory structure <stikonas>you run make DESTDIR=/tmp/stage install, then checksum all files in stagedir <stikonas>and move the whole thing into your prefix <stikonas>(now we are installing and then checksumming) <fossy>the thing I like about stow is is that when we go to sysb sysc sysd etc, we can just copy over package directories that we want <fossy>although that is also doable using destdir <stikonas>yeah, if you have a list of installed files <fossy>Ill see if I can get stow working <fossy>if its not trivial destdir is probably the way to go <stikonas>destdir have a slight advantage that we can use it earlier <bauen1>a bit of bash + sha256sum + tar + stow would probably make for a decent-ish package manager, just need to integrate all the things together <stikonas>basically something to keep track of what is installed *bauen1 wonders if it could be made to be compatble with .deb so bootstrapping becomes very easy once you have dpkg running <stikonas>dpkg probably needs newer perl than what we have <stikonas>but they are more useful for dealing with binary packages... <bauen1>stikonas: i mean you can make it as complicated as you want, you could have stow manaage the entire sysroot for you (and "upgrade" packages when they become available) <bauen1>stikonas: i was thinking about when you want to compile the source packages for the first distribution, if you provide dpkg packages that can then be used as build requirements for other debian packages you could rework the entire debian dependency graph to remove any cycles, the only input would be the debs generated from a successful bootstrap <bauen1>s/the first distribution/a distrbution/ <stikonas>well, at some point it might be good to do that, but it would be nice to do that for various distros, not just debian <bauen1>true, but you have to start somewhere <fossy>I have too many issues with dpkg. <stikonas>well, if we have some list of files and packages even from bash, it should be trivial to create deps <stikonas>but I think it makes sense to do that much later <fossy>it is not very useable, the packaging format is absolutely insanly complex <stikonas>yeah, debian packages are more complex ... <fossy>all we need is something that is able to track files, dpkg is so overkill <stikonas>but I think even "ebuild" program is overkill here <fossy>the thing that distinguishes us from distros is this process is empheral, we always start from 0 <bauen1>fossy: yes not for now, i was thinking at the end you could just tar up the most up to date packages in the stow directory, add a bit of metadata and then use that (after building a few debian tools) to bootstrap debian <stikonas>I gues any real distro package manager is too complex here <fossy>therefore we dont need dependency resolution <stikonas>I think we can just make binary deb packages for bootstrapping without source debs <stikonas>just archive e.g. gcc files using binutils ar into binary deb <stikonas>we don't even need dependencies for those bootstrap debs later... <stikonas>anyway, I think distro bootsrapping is for much later... <pder>stikonas: I just tested a qemu build of your latest gcc branch and it succeeded <Hagfish>bauen1: should the goal be for a bootstrapped system to produce binary .deb files, or to produce a Debian base image (or does the latter require the former)? <bauen1>you know what instead of sitting here doing nothing but waiting for something to happen and solving sudokus, i could be helping here, so let me try out live-bootstrap and see if i can get gnu stow to build <bauen1>or find an alternative implementation that does build <Hagfish>if it helps, i think there are some pretty good sudoku solvers out there which could automate that task for you, although i don't know how reproducible their builds are ;) <bauen1>if i run chroot with --userspec=1000:1000 (to not give live-bootstrap root access more than necessary) does that break sha256sums ? <bauen1>Hagfish: ideally you can bootstrap multiple distributions from live-bootstrap ? i was just thinking about how a transition to a debian system might happen <stikonas>not sure if sudoku solvers can do package management... package managers on the other hand can solve sudoku <bauen1>stikonas: i've read somewhere tthat apt basically does SAT solving against the package versions, so that is probably true ... <stikonas>anyway, dependency resolution is not needed here... <stikonas>although, it might be nice to produce dependency graph <bauen1>Hagfish: i think you'd eventually build *dpkg*, "package" all the existing bootstrap tools so you can use dpkgs dependency resolution, and start building all the tools that are part of build-essential <Hagfish>yeah, i guess you'd need the packages that are part of build-essential <bauen1>Hagfish: then build the debian kernel using that, reboot, and start building the packages necessary for the debian installer and package management, once you have those you can hopefully produce a bit to bit identical installer as debian.org provides <Hagfish>presumably the debian buildd admins spin up a base system and then install build essential on top of it <bauen1>you might need a few more other thigns to go with it, like gpg, nginx, ssh, to take care of your infrastructure needs <bauen1>stikonas: yes, once you have dpkg and build-essential it should be a smooth sailing ship <stikonas>well, smaller distros are even easier... <stikonas>I've added one more comment about that workaround... <bauen1>by the way, how long does live-bootstrap currently take on a compuer that's not a potato ? <stikonas>bauen1: with GCC changes maybe slightly over <stikonas>bauen1: also depends on qemu vs chroot... chroot is faster, qemu is a bit slower <stikonas>bauen1: I expect it will start growing a bit faster now <bauen1>nice that doesn't sound too bad, i suppose that will change once the next few gcc / binutils versions are added <stikonas>that said, maybe we should build without too many optimizations... <stikonas>much faster to bootstrap gcc, then e.g. rust