IRC channel logs
2024-01-24.log
back to list of logs
<oriansj>nimaje: the value of libcs tend to be less about the functions included and more about the programs which can successfully be built with it. <matrix_bridge><Lance R. Vick> rickmasters I was more meaning in the later stages of live-boostrap it shipping with coreutils/curl. Curl alone has more dependencies than than busybox as you need perl/openssl or gnutls/nettle/gmp. I'll have to take a closer look at the build order though as I am probably missing something obvious. <matrix_bridge><Andrius Štikonas> well, I think we looked at busybox before bash <matrix_bridge><Andrius Štikonas> and it looked infeasible because of libc requirements/build system <matrix_bridge><Andrius Štikonas> and after that standard stuff was just building... <matrix_bridge><Lance R. Vick> Yeah I mean I built busybox straight away from live-bootstrap with no problem as I didn't want to have to carry and rebuild bash/curl/gmp/gnutls or perl/openssl for just a bootstrap container. For busybox I just needed musl, binutils, and make. <matrix_bridge><Lance R. Vick> and the existing shell you already had, of course. So yeah I imagine the issue is needed a traditional shell early, and bash was easier to reach for than busybox when pivoting from kaem or something. <matrix_bridge><Lance R. Vick> That pivot point still seems like magic to me. I need to go dig in there more <matrix_bridge><Lance R. Vick> but been focused on getting my higher-level stack bootstrapped atm <rickmasters>*sorry for cut and paste. Virtual Box doesn't handle serial by default if I remember correctly. <Googulator>It also makes perfect sense on bare metal to not use serial <Googulator>otherwise the build output will clobber tty2 and beyond <matrix_bridge><Andrius Štikonas> you just call another process and that's it <matrix_bridge><Andrius Štikonas> the real magic is in kernel bootsrapping 🙂 <lrvick>I meant more, you have to compile up to bash/binutils/gcc etc from kaem. <lrvick>but yeah the low level kernel stuff seems another level of bonkers <lrvick>I am just happy of whatever hashes you publish from all that match mine in container land <stikonas>stage0-posix already has kaem stuff scripted and it's not that complicated anyway <stikonas>then goes mescc (for which we had to handwrite kaem build script, it's a bit longish but is basically just a list of files to compile) <stikonas>after that goes tcc, which has a nice option -DONE_SOURCE=1 which basically means that you can just compile tcc.c <stikonas>(of course in real life it's a bit more complicated than that, you also need to rebuild mes libc but it's not too bad) <stikonas>if we don't do kernel bootstrap, then after tcc we have a short kaem script to build make <stikonas>and after that we basically write makefile rules <matrix_bridge><Lance R. Vick> Yeah, each individual bit does seem pretty simple <matrix_bridge><Lance R. Vick> making the whole puzzle work, not so much, but fair enough. Thanks <matrix_bridge><Lance R. Vick> I may take a stab at documenting the whole stack layer by layer at some point to help people audit it easier. <matrix_bridge><Lance R. Vick> but it was easy enough to read and conclude nothing fishy is going on <stikonas>well, the worst thing that might be remaing is some pre-generated files <matrix_bridge><Lance R. Vick> oh! this is exactly what I wanted. All I have had to go on was the guix blog post, which is not 1/1 to what you are doing <stikonas>for some reason software maintainers love including them in the releases... <stikonas>again, it's just a path, not the only possible path <stikonas>but it does explain some of the choices... <matrix_bridge><Lance R. Vick> Yeah I will be going over that in much more detail. this is exactly what I wanted. <matrix_bridge><Lance R. Vick> must have missed it in my hurry to start implementing. <matrix_bridge><Lance R. Vick> I already had my whole deterministic distro for things like rust toolchains, but it was bootstrapped in alpine which undermines my whole software supply chain model of no single trusted party. The timing of the work here could not be better for me. <matrix_bridge><Lance R. Vick> and it is dramatically easier to trust than alpine, given I can triple build stage0 and get the same results from different distros, then carry on from there into live-bootstrap, though the "live" part is not really useful in my setup <matrix_bridge><Lance R. Vick> I like that it exists, and should in theory get the same hashes for the contents of my stage1 container <matrix_bridge><Lance R. Vick> I feel like anyone that goes down the obsessive rabbit hole of deterministic builds is bound to end up here eventually. <stikonas>yeah, it's just makes so much sense to start with single binary and follow a well defined process <stikonas>than trying to somehow start from various big environments and somehow build up to the same thing <stikonas>almost all reproducibility in bootstrapping is for free... <stikonas>just needed occasional tweak or small patch (mostly to get rid of timestamps) <matrix_bridge><Lance R. Vick> Yeah I got here because I built a whole package pinning system on top of debian, and the debian archive is unreliable, so almost every repo ended up requiring an LFS folder with 3GB of packages to deterministically build anything, and know we can reproduce it in the future. <matrix_bridge><Lance R. Vick> But now that I can boostrap a deterministic rust compiler all the way from stage0, then I can just have developers use the locked hash of the container with that compiler, and anyone can repo the same rust compiler contanier from stage0 too. <matrix_bridge><Lance R. Vick> then I have a multi-signing setup and policy thing <stikonas>well, we do have a similar problem though <stikonas>but probably nowhere as bad as 3 GiB of binaries <matrix_bridge><Lance R. Vick> Well at least the source tarballs are lots of mirrors, and only needed for build reproduction. Not something I have to force every dev to carry locally <matrix_bridge><Lance R. Vick> I may LFS mirror all the sources from stage0 up in my own repo for those building, with pgp keys to verify I didn't tamper with them. <matrix_bridge><Lance R. Vick> The next things I am building on top are a bootable airgapped OS for keygen ceremonies, and a bootable linux/rust unikernel for enclaves... both of which will be used by use cases where no single party can be trusted, including anywhere in the supply chain. I hated even trusting debian for this previously as any single maintainer... yeah <stikonas>Googulator: why exactly do we need to switch tty's for each new bash? <stikonas>because we don't want multiple processes writing to the same tty? <Googulator>We only do this for the monitoring shells, not the ones actually running the bootstrap <Googulator>So you can Ctrl+Shift+F2/F3 away from the continuously scrolling text, to check something in a shell, while the bootstrap is still running in tty1 <Googulator>We can't reuse tty2 for bash 5.2, unless we find a way to programmatically identify and kill the bash-2.05b process running on it <Googulator>Also, if the user is currently doing something in the 2.05b monitor shell when 5.2 is done building, we don't want to pull the rug from under whatever's running <stikonas>anyway, good job sorting out all these issues! <Googulator>Mikaku: any idea why pressing Num Lock or any other Lock key in Fiwix booted via kexec-fiwix could cause a lockup on bare metal? <Googulator>other than that, the keyboard works, although it's probably relying on BIOS emulation <fossy>lrvick: "making the whole puzzle work, not so much" is very accurate, most of that early work was copied from guix's path just because it's so hard to find the optimal version combinations <fossy>and we still haven't got the most optimal version combinations <fossy>Googulator: #415 supersedes #328? <fossy>looking pretty good. will just review for pregened files <Googulator>The only thing in 328 that's not in 415 or previous PRs is the "reboot" script (instead, exiting the final shell powers off), and the extra memory map entry for 8G RAM support in Linux (which needs to be done dynamically by reading the real e820 map) <fossy>yeah, there's a couple of pregenerated files in grub <fossy>also, does installing grub overwrite any of builder-hex0? <fossy>i suspect not, but just wanted to check <Googulator>on UEFI, it wouldn't do that, but of course we don't yet support UEFI at all <stikonas>yeah, we are nowhere close on UEFI yet... <stikonas>though right now main blockers are amd64 support in userspace bootstrap <fossy>yeah, cause we have to get to tcc to get to fiwix... <stikonas>I've just sent a fix to mes earlier today but we need quite abit more <stikonas>and with my fix it can even compile crt1.c <stikonas>I can build it if I add some stupid patch <stikonas>i.e. if I add "mode;" line in one place of tcc code <stikonas>but then later it still crashes when I try to build tcc-boot0 <stikonas>of course after that there is still trampolining into Fiwix... <stikonas>there is also some bug in posix-runner that I haven't fixed yet <stikonas>after 30 or so invocations of mes-m2 it fails with non-zero exit code because last free() call before exit() fails <stikonas>splitting kaem script into smaller works around that but is again not very satisfactory <stikonas>so yes, some progress, but not there yet <Googulator>fossy: looks like gnulib is handled in a really ugly way in grub <Googulator>the script required to load it is stripped from the official tarballs, only found in Git <stikonas>usually when we have to build some non-gnu stuff, say xz" <stikonas>which is why some packages, ship git snapshot as well... <Googulator>in fact, grub 2.12's tarballs are unusable because the script to prepare the tarball strips out too much, breaking the build <fossy>Googulator: the usual workflow for gnulib we use is to take the gnulib-tool command given in Makefile.am within lib/gnulib directory, and run that manually, rather than using gnulib regeneration scripots <fossy>which are usually absolute junk <Googulator>probably distros are just compiling the Git sources, rather than the tarball <stikonas>but in coreutils some files are missing in release tarball <stikonas>i.e. occasionally we had the case that gnulib-tool only works on git repo and not on release tarballs. Though usually it works on both <fossy>oh, yeah grub 2.12 is broken <Googulator>found the command in Makefile.am - unfortunately it doesn't tell me which gnulib revision to use <stikonas>they also still haven't included proper LUKS2 support in grub <fossy>nope, ususally gnulib is a submodule, so i go to the release tag in the git repo and find the revision they used there <stikonas>somehow grub project doesn't seem very healthy these days <fossy>i think there's like one maintainer lol <fossy>i think probably just because that's the link i copied <Googulator>we seemingly always use .gz for gnulib, and nothing else, when downloading from savannah <stikonas>some early gnulib tarballs are from former sysa and predate xz <stikonas>also I think we have somewhat insonsistent length of hash for gnulib tarballs... <fossy>using said files in unicode/ <fossy>technically, they probably are pregenerated by something <fossy>but they're effectively csvs with ; instaead of comma <fossy>ohhh, thats for a specific gnulib module, pregenerated unicode data in gnulib itself <Googulator>vs "imperial" ones which use , as separator and . as decimal <Googulator>metric countries generally use , for decimal separator <stikonas>and in some countries , is decimal separator for numbers... <fossy>$AU , is number separator, and . is decimal separator, eg 1,000,000.00 <fossy>i know some places do 1.000.000,00 though <stikonas>but e.g. in Lithuania we used 1.000.000,00 <fossy>Googulator: don't worry about that part of gnulib script in coreutils, grub does not import any unicode junk from gnulib <Googulator>CSVs use , in the former British empire, and ; elsewhere <Googulator>and since Unicode is all about supporting languages other than English, the "Metric" version wins for Unicode <Googulator>fossy: do you see anything that needs fixing in #418 that needs addressing? <Googulator>If not, I'm considering swapping the dependency there <Googulator>stikonas: slightly wrong, the plural of "stone" is "stone" when weighing people; Brits are adamant about this <Googulator>hmm, what is even the long form for "ln -s"? I've only ever seen it written like this, including in live-bootstrap. <fossy>but ln -s is the only one i've ever seen used <fossy>i don't mind use long options, but when it's really common and a defacto standard (eg, ln -s, ls -l, etc), ones that everyone who uses linux will have come across, i think it's no benefit to readability, and a waste of time to bother about <fossy>yeah, specifically common ones <fossy>Googulator: the changes from solely #418 look fine to me <matrix_bridge><Andrius Štikonas> But various more obscure ones can definitely make a difference between having to read manpage and not <fossy>if one needs to realistically open a manpage then long options good <Googulator>OK, inverted the dependency between #415 and #418 <Googulator>of course, bootstrap.conf is deleted from the release tarball, because, why not? <Googulator>fossy: po/Makefile.in.in is fine in the case of grub? <fossy>it's not like any actual processing is done to it in coreutils, i think that was to fix a build error in coreutils <Googulator>I consistently get right checksum when I download from here <Googulator>be it rootfs.py, download-distfiles.sh, or my browser <fossy>did you forget to git add sources or something? that is very strange <Googulator>No, it seems as if Savannah generates different xz's depending on geographical location <Googulator>1906873542ae6d3d4700e069dcb0e7f21c68c28ede23a55a7c55f968cf5c4730 matches all copies of the xz I downloaded <fossy>that is absolutely stupid, different xzs depending on location <muurkha>it'd be interesting to compare the different xzs to see if some of them contain a possible backdoor <matrix_bridge><Lance R. Vick> Yeah that is... sketchy. Do you have examples of the two xzs ? I would very much like to diffoscope those. <matrix_bridge><Lance R. Vick> if you have the URL, I would like to test it from different IPs as well. Source backdoors are the next biggest risk, so for sure want to chase this even if it is nothing <matrix_bridge><Lance R. Vick> Also extra interesting if anyone signs these sources, and which one they sign <fossy>a load of small changes to work toward a bit-by-bit fs <muurkha>fossy, Googulator: do you have copies of the two different .xz files? <fossy>my sha is 1906873542ae6d3d4700e069dcb0e7f21c68c28ede23a55a7c55f968cf5c4730 when i download it normally <Mikaku>Googulator: regarding the Lock keys in your USB keyboard, well, no idea, I only use PS/2 keyboards. Perhaps your keyboard sent a strange scan code that the Fiwix keyboard driver didn't know <Mikaku>Googulator: you might want to add a 'printk()' in the keyboard driver to see the scan code that gives your Num Lock key in your USB keyboard <oriansj>well optimal bootstrap wasn't the goal as for a long while the goal was just to get a working bootstrap; lots of shortcuts and guesses were done and it'll take a long while to actually optimize all of the steps down. <oriansj>improvements to the libc used can easily open up more and newer tools to simplify various steps and potentially shrink the total live-bootstrap toolchain in big ways. <Mikaku>rickmasters: I plan to remove the Fiwix kernel option CONFIG_OFFSET64 because it is only used in the fd struct but all the functions are using 64bit offsets without considering this option <Mikaku>rickmasters: the problem is that you reference this option in docs/tcc.txt <Mikaku>rickmasters: can you, please, check if TCC can build the kernel even if the offset element in fd struct (include/fiwix/fd.h) uses the type __loff_t? <rickmasters>Mikaku: I'm pretty sure tcc cannot build with the 64-bit type and that was the reason for CONFIG_OFFSET64 <Mikaku>rickmasters: but then how come it can deal with functions that uses 64bit values? <rickmasters>Mikaku: tcc can generally support 64-bit variables, but if there are math operations on those variables it is more complicated. <rickmasters>If there are math operations then some support functions need to be compiled in. <rickmasters>But Fiwix is compiled with options that exclude standard library and libtcc which have the functions. <Mikaku>yes, you mean __divdi3 and friends <rickmasters>It may be possible to include the 64-bit math functions manually, but I wasn't able to figure it out after some time working on it. <Mikaku>no worries, just wanted to make sure that the option CONFIG_OFFSET64 is still somewhat important <rickmasters>Mikaku: Sure. Maybe we should add an Issue or information in the docs for future reference. <rickmasters>Mikaku: I think its possible to make it work someday. <Googulator>TIL `ed` can be used as a substitute for `less` in a pinch <Googulator>which gives me an idea to add some kind of logging facility <fossy>stikonas: is it to be expected that stage0-uefi is fairly slow <fossy>or is that specific to my hardware <fossy>possibly the usb drive im using is slow... <fossy>took around 45 seconds to get to hex1.efi <stikonas>it is noticeably slower than stage0-posix <stikonas>but some of it might be due to slower USB vs SSD... <fossy>i suspect it's my usb then lol <fossy>i havent used this usb in at least a year <stikonas>I think I'm using something like 8 year old... <fossy>this one is probably around the same age... <fossy>i'll try the same usb on different hardware once this one finishes <fossy>oh, yes, it's progressing, just with not very much speed at all :P <fossy>i suspect the IOPS is garbage on this, it's just a generic nobrand usb <stikonas>I found UEFI has fairly low tollerance to bad bahaviour compared to Linux <stikonas>so if you don't follow the spec, chances are that UEFI would just crash <fossy>yeah we haven't crashed (yet) <stikonas>but if it's running but slowly, then that's good <fossy>i'll let you know the results <stikonas>if you are using the latest commit it should build up to posix-runner (though last one is not checksummed yet) <stikonas>if it's I/O, it might speed up a bit once full M2libc is used 