<OriansJ`>well less bytes in hex0-seed is probably a good idea; things built by hex0 problem benefit more from being easy to understand. <OriansJ`>although I am tempted to make sin.hex0 part of the bootstrap-seeds <OriansJ`>as it'll flag all bytes that are not 7-bit ascii characters <OriansJ`>so that sneeking in unicode or other source hiding tricks impossible from the start. <OriansJ`>such as the unicode RTL and LTR characters or zero space characters <stikonas>i.e. file size would be bigger by a few bytes <stikonas>well, that's one more check your have to do but doesn't seem particularly hard <stikonas>hmm, maybe it depends on where the bootstrap is happening <OriansJ`>stikonas: depends if you are just doing an injection, replacement or an ordering attack but they would all result in different binaries with different checksums (which should be huge red flags too) <OriansJ`>It is mostly just making attacks impossible to hide in an ever shrinking number of places. <OriansJ`>right now the example stage0 rootkit hooks into the unique read/write a single byte behavior to inject the attack <OriansJ`>but it requires a compromised kernel to do it <OriansJ`>(if I remember correctly bauen1 did that work) <OriansJ`>but bare metal ports would detect such attacks rather easily. <siraben>OriansJ: I haven't looked into the hex+ stages or M2-Planet yet to say how it would be improved. <siraben>However, assuming enough effort, here's my sort of vision for an alternative bootstrapping path via a more FP oriented way: keep the early stages up to the assembler, then write something like blynn-compiler's vm.c in assembly, then bootstrap Scheme on top of the Haskell dialect <siraben>the reasoning being that the earlier we reach a functional language the easier auditing will be, and so would having a typed language that GHC/Haskell 98 accepts <siraben>but that's just my opinion, I think the more diverse paths we have the more confidence we can put on future-proofing our work. <nore>I don't know who is in charge of bootstrappable.org, but it seems like https certificates are broken since a few days (2021-02-27) <bauen1>OriansJ`: i made a "stage0" "rootkit", so an evil hex0 that is very similiar but hooks any resulting binaries (and can propagate to some extend) <nckx>nore: Thanks for the report. <nckx>It's hosted on berlin.guix.gnu.org but uses a different configuration (dunno why) that can't work, so it will never auto-renew. Had to shut down the entire Web server. <OriansJ`>bauen1: thank you for correcting my mistaken memory. ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<pder>stikonas: I updated my bash branch and rebased it on your binutils branch. Again, very nice work- things are really coming together. <stikonas>pder: well, I guess bash is still not reproducible? <pder>what do you mean by reproducible? <stikonas>pder: sometimes they are not... maybe it doesn't affect bash <stikonas>pder: but at the moment ar (and ranlib) do not yet do zero timestamps <stikonas>this might not affect executables, but it does affect .a archives <stikonas>but maybe timestamps do not propagate to elf files <stikonas>I would still like to patch them out before marking PR as ready <pder>didnt you mention that later binutils has an option for that? <pder>could that patch be backported? <stikonas>pder: kind of... I was doing manual backport (code changed sligthly), but somehow timestampts were still there <stikonas>I probably missed some other patch too... <pder>In any case Ive done several builds of my bash branch both with chroot and in qemu and checksums match <stikonas>but basically just need to get rid of stuf like time, user id / group id and file mode <stikonas>ok, I guess it doesn't propagate to elfs <stikonas>I tried musl, but libc.a is different every time <pder>Did you try doing a binary diff of libc.a before and after? <stikonas>(midnight commander when I enter .a archive) <stikonas>but need to find where they are inserted... <pder>something like diff -y <(xxd libc.a) <(xxd libc.a-after) <stikonas>I think they are taken from object files in our filesystem, so probably some stat call <stikonas>although, if bash is reproducible, we can merge binutils and I'll continue looking at this after merge <stikonas>and after that I guess can try looking at gcc... <stikonas>there is a range of versions that we can try... <stikonas>I think 2.95.3 would need tcc-mes (interestingly that one does not use autotools), gcc 3.x or 4.x might be more compatible with tcc-musl <pder>you dont think musl would work with 2.95.3? <pder>stikonas: not sure if you looked at the binutils git repo but here is the commit that introduces deterministic output: 36e4dce69dd23bea9ea225 <pder>maybe we want to patch our binutils so that is the default behavior? <pder>Here is the git url: git://sourceware.org/git/binutils-gdb.git <stikonas>pder: yes, that's what I was looking at on Sunday <stikonas>I might take a look again today, started live-bootstrap now <stikonas>pder: argh, I think it was a stupid error on my side <stikonas>I was running binutils build script, but it does not call into default_src_prepare <stikonas>we should add some echo to applying patches stage ***V is now known as v
***v is now known as V
***edef is now known as EDEF
***Noisytoot is now known as N
***N is now known as Noisytoot
<stikonas>I've also added a commit to print "Applying patch: " message <stikonas>to avoid getting into the same situation <stikonas>tcc was patched to work with this patched musl <pder>It might be worth trying either way even if it doesn't prove necessary <stikonas>might be worth just running tcc's configure script now <stikonas>we should have everything for it now (including uname) <pder>Oh, dirname is also needed for gcc, but its just adding it to the pass2 makefile <pder>I ran into similar problems as with binutils related to certain types like size_t <stikonas>with musl I got some error in alltypes.h or something like that <pder>The way to fix that is to find the offending type and remove it from config.h <stikonas>well, gcc will be our biggest package so far... <stikonas>but on the other hand, after it things are almost done <stikonas>musl will have to stay as static library for now... <pder>we will then have to incrementally build gcc, binutils, and glibc until we have a c++ compiler, and then modern gcc <stikonas>I'm not even sure if we need to build glibc and binutils right now <stikonas>we might be able to just build old gcc -> newer gcc -> even newer gcc <stikonas>unlike guix bootstrap, we already have modern libc <stikonas>but maybe old glibc will be more compatible... <pder>it will take some experimenting for sure <stikonas>pder: oh I think I also saw some problems with sed when trying to configure gcc...