<oriansj>I'll have it updated in stage0-posix before I do the release. (hopefully everything else is making you happy ^_^) <stikonas>I'm now at the stage where I fix checksums, just fixed sed, patch is next and after that I think it should build till the end <stikonas>(cause now we will be using sha256sum from the very beginning, no need to use fletcher) <stikonas>but I do need update in stage0-posix before I make PR... <stikonas>I still need to finish things and then tidy up bit (go over readme, etc...) *stikonas goes back to #nethack game while live-bootstrap runs <oriansj>stikonas: I'll get that release out once I finish testing aarch64 (it'll be a minute as it is enitrely qemu emulated) <stikonas>I was just wondering whether release is e.g. days away or soon <oriansj>stikonas: in this case it'll be the time it takes for stage0-posix to run from start to finish twice on AArch64 (so an hour maybe) <stikonas>at some point it should be good to add aarch64 qemu option to live-bootstrap. Even if it doesn't run to completion <oriansj>AMD64 would be a cheap and easy half-step <oriansj>and flush out all of the 32bit problems before you add the issues of a new architecture ontop of it <stikonas>well, for now I'll leave it in case somebody else picks it up <oriansj>So you can do the conversion one program at a time <oriansj>although the first big blocker would be we don't have an AMD64 build of mes-m2 yet <stikonas>and also code branching has to solved. kaem doesn't have any way to do conditionals <stikonas>something can definitely be written, but I'm not sure what's the nicest way <stikonas>I guess hard to tell until somebody starts doing the work <stikonas>well, all checksums will definitely change, but also some builds/installation scripts <oriansj>stikonas: no problem just define a single variable ARCH and the checksum file becomes SHA256SUM.${ARCH} <oriansj>when the code needs to branch kaem -f thing.${ARCH} <oriansj>So not the most optimal solution but it does give a possiblity to do it without kaem changes. But what is wrong with enhancing kaem more? As long as M2-Planet+M2libc can build it go crazy <oriansj>which reminds me I need to add support for short and uint16_t to M2-Planet so that we can properly support STAT syscalls <stikonas>yeah, enhancing kaem more might be better <oriansj>or someone could implement a mini-make in the M2-Planet subset if that sounds like fun <stikonas>ok, so far live-bootstrap is running well, already reached gcc <oriansj>Now the problem set for attackers is to compromise a sha256sum build chain starting from a 357byte seed. <oriansj>or sha3 depending on what we want thanks to mihi adding sha3 to messc-tools-extra <Hagfish>it's getting close to the point where the most fruitful line of attack would be to find new discoveries in mathematics or physics <oriansj>So a multiple crypto cross checking build chain <Hagfish>that would be easier as a defender than the attacker's job <stikonas>oriansj: do you remember if sha256sum from mescc-tools-extra works with large files (> 2MiB)? <stikonas>I guess I can check once my live-bootstrap finishes <oriansj>stikonas: I believe so but I'll double check with a nice fat 400MB file <stikonas>Hagfish: well, mathematics itself is like that, you can't prove within your axiom system that your axiom system is consistent. <stikonas>oriansj: oh, maybe we don't need to bother then with coreutils-6... <stikonas>Hagfish: also there are things you can't prove in maths given those axioms <Hagfish>yeah, and you can't prove that there aren't any quicker algorithms for breaking RSA or finding reverses of hashes <oriansj>well it does 13MB files fine (a bit slow but it works) <Hagfish>or prove that a 2048 bit key is stronger than a 1024 bit key (and obviously not all 1024 bit numbers are equally good as keys) <oriansj>and completed a 400MB+ file correctly <oriansj>(Took about 5 minutes to do 400MB in M2-Planet+M2libc built sha256sum) <oriansj>(I used the void-live-ppc-20200411.iso from my PPC32 mescc-tools attempt, never could get it to give me something useful so I probably missed something obvious) <stikonas>maybe a bit slower when built with M2-Planet (that was built with tcc) but more correct <oriansj>stikonas: sha256sum.c is certainly buildable by tcc and GCC and will also work correctly <oriansj>So rebuilding it after tcc for speed improvements isn't a bad idea <stikonas>also using ungz, etc will be left for later commits <oriansj>it'll certainly allow the clean up of git submodules and significantly drop live-bootstrap's .git size <oriansj>and stage0-posix release v1.3 is now officially out <stikonas>I think it will work with live-bootstrap <stikonas>I'll have to fix one more thing, but I think that's inside live-bootstrap <stikonas>because it automatically hooks up to your after.kaem hook <stikonas>I guess because you used the same file name <stikonas>anyway, going to bed, so will test more tomorrow <oriansj>sweet dreams stikonas and great work as always ^_^ ***jackhill_ is now known as jackhill
***terpri is now known as robin
***ChanServ sets mode: +o janneke
<siraben>I was sharing live-bootstrap to a CS friend and they brought up this question: <siraben>"but how do you trust the machine that runs the hex0 binary in the first place?" <pabs3>run it on multiple of them and check the results against each other? <Melg8[m]>siraben: i think oriansj have a plan for implementing it's own hardware running knight (that's one of arch targets in his repos), and now it runs on emulator <stikonas>in general bootstrapping will not help if your hardware is already malicious <stikonas>the only solution is to switch to non-malicious hardware <fossy>yeah exactly what stikonas said <fossy>hardware bootstrap is a completely unsolved problem :| <fossy>i've been thinking about that problem <fossy>i think riscv is the solution <stikonas>well, but reallistically you can only build simple riscv board <fossy>cause you can start with something like ttl but then you need something that can viably run linux and cross-compile to other architectures while being provably verifiable <stikonas>even if you build good binary on your home-built riscv <fossy>i think we can treat open hardware similarily to open software auditing though <stikonas>there is no guarantee that good binary would work correctly on other malicious hardware <fossy>fpags are hard to verify but yea <ekaitz>yes, the bitstream generation is... proprietary <ekaitz>and we don't have any way to know what do we have inside of the FPGA <oriansj>siraben: doing DDC on hardware comes with a great many restrictions, the first of which being that a single unmodified run does not imply that the machine isn't compromised. So even though we have the ability to cross check all architecture bootstraps against each other (which will spot any malicious changes that occur); we would not be able to know for certain that there are not malicious circuits waiting to be triggered. (eg twiddle <oriansj>this register between these 8 values a few thousand times to unlock bad thing) <oriansj>So in my view only things like LibreSilicon and local foundries would enable one to obtain trusted hardware. <oriansj>Building out a computer out of individual logic gates would enable one to use untrusted foundries to build a computer capable of checking for the always on compromise behaviors but depending on how slow it is, it might not be able to detect the infrequent compromise behaviors. <xentrac>oriansj: if you built a computer out of discrete logic, like the 500kHz Pineapple One, you could hypothetically imagine that someone had replaced one or more of your discrete-logic chips with a rebadged Padauk microcontroller or something <xentrac>which could be programmed to act like a logic gate most of the time, but then do something like the twiddle-this-register trick to provide a backdoor or exfiltrate data <ekaitz>yeah I know it but still, the FPGA implementation is obscure <oriansj>xentrac: excellent point but I'm not sure how exactly that could work in isolated NAND, NOR, AND, OR, XOR gates <oriansj>ekaitz: we can only solve the problems we can put our hands around. <oriansj>So it is best to look for something that needs to be solved and fun to do and attack that. <ekaitz>that's why as you mentioned libresilicon is important! <ekaitz>but yeah atm FPGAs through Icestorm are good enough <stikonas>still you have to trust your manufacturer, even if silicon is libre <oriansj>ekaitz: indeed, some progress is always welcome <oriansj>stikonas: I don't plan on growing trees for lumber to produce charcoal anytime soon unless some serious shit goes down ^_^ <stikonas>yet pulling off trusting trust attach in hardware would be even harder than in software <stikonas>and even in software there is no evidence of them <stikonas>(there is more that can be done, but probably best to leave it to later PRs) <xentrac>oriansj: if you have LibreSilicon and local foundries you can verify what what you think is an isolated NAND gate is really a NAND gate and not just a microcontroller programmed as an in-circuit emulator of a NAND gate :) <stikonas>what would help are probably independent audits... That's what other fields do <stikonas>well, maybe it's easier to audit small local foundry <siraben[m]>matrix bridge had issues, last message I saw was "<xentrac> which could be programmed to act like a logic gate most of the time, but then do something like the twiddle-this-register trick to provide a backdoor or exfiltrate data" <xentrac>it's probably worth mentioning bunnie's arguments in favor of FPGA CPUs <xentrac>the Pineapple One is RISC-V btw. I think at 500kHz it's probably not a viable way to run GCC ***ericonr- is now known as ericonr