<OriansJ>melg8: Well that will work if you wanted to use an untrusted system to perform the bootstrap calculations, you would still need a trusted system to decode the final result to make it useful. <OriansJ>Further if your system was compromised by a trusting trust attack, the decryption process could be compromised to change the resulting binaries to infect them on decryption. <stikonas>and if you monitor is hardware compromised, it can show different source code that what is on the disk (that's REALLY unlikely though) <OriansJ>That is why DDC is the only known solution to the Trusting Trust attack <OriansJ>stikonas: that would be a Nexus Intruder class of attack (Compromise hardware to make software only bootstraps useless) <melg8>so now we all seeing some layer of untrusted hashes? it is consistent, but in theory - they all could be mocked? <OriansJ>melg8: Well perfection is a road, not a destination. <OriansJ>So this is the best attempt we have to date. <OriansJ>Which might be compromised but it is in a form discovering it when we work around additional attacks become trivial <melg8>That reminds me Kongres futurologiczny by Stanisław Lem <OriansJ>So each attack becomes harder and harder; until they would have to compromise Physics itself <stikonas>and it excludes realistic trusting trust attacks <stikonas>well, can't really compromise Physics... <OriansJ>stikonas: yet, then fuck all assumptions we have about security and figure out how to compromise physics ourselves. <stikonas>you might discover more laws of physics that were not known to humanity but the laws were there all the time <OriansJ>stikonas: true but again, we are doing our best approximation of a step in the correct direction. <OriansJ>Even our wasted efforts and compromised builds bring us closer to solution. <melg8>Why this project is developed by small amount of people, and not like big tech + government? does that mean that they think that this is not realistic attack vector? <stikonas>first of all most people including big tech + government just use binaries <OriansJ>melg8: because their last major attempt cost $8Billion and failed to produce meaningful results <melg8>@OriansJ what you talking about? <stikonas>and I guess other attack vectors are indeed more realistic <OriansJ>melg8: The Trusted Weapons system Initiative under Reagan which was a giant cash give away to software companies <stikonas>it's probably easier to insert backdoor into something like management engine than into compiler <OriansJ>stikonas: it ends up being easier to compromise the Microsoft update mechanism and push targeted updates <stikonas>well, tccboot replaces kernel bootstrap problem with tcc blob <melg8>for removing kernel from the binary input part of things <melg8>can tcc be achieved without kernel itself? <OriansJ>melg8: It just becomes a Kernel with C compiler functionality <Hagfish>to some extent the "best case" outcome of a successful bootstrapping process is proving that the software you are already using is based on the code you thought it was <OriansJ>So it isn't better than live-bootstrap with a kernel smaller than the tccboot blob <stikonas>and live-bootstrap has some advantage that it's kernel independent <stikonas>so trusting trust attack has to work on absolutely any kernel <OriansJ>So any sub 138KB kernel would be a smaller root than tccboot <melg8>but this kernels - build with our friend gcc? so it could indeed be trageted towards infecting new builds of gcc <Hagfish>i'm not sure what the half-life of military secrets is, but if a Trusting Trust attack had succeeded in the 70s, and placed a backdoor in all software in the world back then, i'm sure it would have been used offensively by now, and thus been detected <melg8>there were reprorts about fake clang binaries with backdoor in china <OriansJ>Hagfish: well end of the cold war resulted in direct sales of chips to the Soviet Union; not so much the reverse <Hagfish>that would make an interesting alt-history novel/film <stikonas>OriansJ: I guess that's because the Soviet union had the largest rockers, the largest tractors and the largest microcomputers <Hagfish>imagine that as the USSR was ending, strategists at the Pentagon were worried about nuclear weapons ending up in the wrong hands <Hagfish>and imagine somehow the US had infiltrated the toolchains of the Soviets, and they had an attack that could only be used once, but it could achieve anything <OriansJ>Hagfish: that is why Clinton Paid 8x for the Uranium and Plutonium from the USSR <Hagfish>it's also why the US funded Russia's space program, right? <OriansJ>Hagfish: I can't speak to that because I am not aware of such a thing but I know we bought the nukes and burned them in US nuclear reactors <Hagfish>i sort of like the idea of the moral dilemma of a vulnerability that applies to all software, friend and foe alike <Hagfish>the danger of having that turned on you must outweigh the advantage of having such a weapon, especially if you hope you'll never need to use it yourself <OriansJ>Well the end of the Cold war forced the problem of all Computers are Global (so both Friends and Foes have the same kit) <Hagfish>yeah, that's where my story breaks down a bit :) <Hagfish>but you're right, we've been heading to more of a technological monoculture, with all the risks that entails <OriansJ>Hagfish: no, because after 9/11/2001 the NSA went pure Offense (less trying to have security vulnerabilties patched) <Hagfish>yeah, which is not just a huge moral failing but a strategic one too <OriansJ>Hagfish: Pride is one of the most dangerous sins for a reason <Hagfish>i wonder how often justice relies on the hubris of the perpetrator <OriansJ>Hagfish: Justice or the Justice System because those are two very different things. <Hagfish>i guess i mean the intersection of the two, which might not be a very large set <OriansJ>Because the first cares not about the hubris but only the Truth but the second depends entirely on the ability to have evidence to convince a Jury/Judge that they are guilty. <Hagfish>it's hard for Justice to be done even with a working Justice System, let alone without it <Hagfish>i don't want to advocate for "mob justice", but maybe "poetic justice" i can allow <OriansJ>So in theory if the perpetrator ensured that there was zero evidence of a Crime, only a corrupt Justice system could convict <Hagfish>but a corrupt Justice System would more often convict an innocent person <OriansJ>but such a system would kill just as easily a truly innocent person <Hagfish>indeed, convicting an innocent person is often easier, if the true perpetrator can't even be found <OriansJ>So the question becomes one of how many guilty people will you let get away with a crime to avoid putting an innocent person in jail? <Hagfish>the fact we are talking only about jail is significant <Hagfish>you can let someone out of jail if they are wrongly convicted (and compensate them, as if they had been kidnapped) <OriansJ>I don't have a good answer for that question because I don't have a good optimization goal in mind for this discussion. <Hagfish>but you can't bring someone back from the dead if they've been executed <Hagfish>i can only rationalise it in terms of insurance/compensation payments <Hagfish>but it's hard to quantify the damage of a miscarriage of justice, not just to the innocent convict, but to the whole of society <OriansJ>I tend to think of it in the following way. Prison isn't an effective use of the people who commit crimes <OriansJ>Nor of the resources required to keep them there. <Hagfish>i do wonder if prison shouldn't include time spent working to pay a debt (but with a government-set wage, so people with market-valued skills can't leave quicker) *vagrantc can't decide if this is #bootstrappable-ethics or #bootstrappable-philosophy <OriansJ>I was thinking of the Babylon 5 solution <Hagfish>vagrantc: to bootstrap a computer, you first have to bootstrap a society :) <Hagfish>i don't remember the Babylon 5 solution <vagrantc>well, compromising physics already came up, society is way further down the toolchain <OriansJ>Hagfish: Death of personality. (mind wipe and convert them into productive members of society who serve the public good) <Hagfish>vagrantc: yeah, and i think the original quote is "to make an apple pie from scratch, you first have to create the universe from scratch" <Hagfish>OriansJ: wow, that's horrifically beautiful <OriansJ>Any community with more than 5 members will discuss/debate politics <Hagfish>if such technology existed, even if it weren't abused, i think it would undermine the lies humans rely on to have a sense of identity <OriansJ>The sign it is a healthy community is that such discussions invite people to entertain the perspective of others and develop more thoughtout view points. <OriansJ>Hagfish: well Babylon 5 was a TV series that included Telepaths as part of the landscape <Hagfish>that would presumably have huge ramifications too <Hagfish>real-world technology may start to raise similar ethical questions <Hagfish>about the 5th amendment, and the 4th <OriansJ>yeah the creation of the Psy-corps and a bunch of laws in Earth controlled space <OriansJ>Hagfish: Only in the United States, else where they have different laws <stikonas>yes, here in UK encryption is already banned... <OriansJ>Like India where censorship is part of their ?constitution? <stikonas>if you don't disclose yoru decryption key, that's 2 years in prison <Hagfish>i don't know of anywhere which has those principles in such sharp relief as in adjacent constitutional amendments <Hagfish>stikonas: right, and then there are questions of whether "i've forgotten it" can be accepted by a jury <OriansJ>better not to know it in the first place I say <Hagfish>you'd have to come up with a clever story to explain why you have random noise lying around <stikonas>random noise might be indistinguishable from encrypted data <Hagfish>yes, the Rubber Hose filesystem does this best <OriansJ>I have a mooltipass; I never knew the luks password, so asking me to provide it does no good <OriansJ>and you can buy really tiny playing cards (1cmx2cm) <Hagfish>i think it was that which said "if the police raid your house, don't panic and throw the cards in the air, because there isn't enough entropy in that" <Hagfish>there's already a case of someone's smart watch data being used to convict their murderer <Hagfish>what happens when these devices are in our brains, as Elon wants? <OriansJ>Hagfish: Not all problems can be solved by entering into the problem space. <melg8>the deadliest of a weapon is compromised ideas <OriansJ>So just like refusing to use Windows, Refuse to use Musky Implants <Hagfish>compromised ideas can be self-replicating <Hagfish>unfortunately it's not enough for us to refuse bad software, we live in a society where other people are in danger if they make those bad decisions, and that threatens us <Hagfish>if bad ideas are like Covid, then Facebook is like a cruise ship ;) <Hagfish>i should have known that Doctorow would capture these ideas so brilliantly <Hagfish>he's one of the great thinkers of our time, at least in terms of tech+society <Hagfish>i do like the short story Manna, which explored similar themes <melg8>Btw,, i have one idea now... about trusted trust attack and DDC as the way to beat it. Am i wrong or for example, if i have untrusted compiler, which i want to check for backdors. And it its written for example in C++11, so when it compiles itself - it produce c++11 builded binary. But what if i subvert compiler to add only backdors to c++20 <melg8>compiled code? and my "trusted" compiler - is able to only compile c++11 but not c++20? will i detect such malicious thing? <melg8>for example - c++20 introduces modules - we give them nice backdoor if detected. but our compiler doesnt have any code with them <melg8>(and you can generalize that idea) <vagrantc>that's why you need to build the same thing with another compiler <Hagfish>if you have a trusted compiler that can compile the c11 code, then that binary will be trusted <melg8>i mean - DDC proposed as technique to validate untrusted compiler <melg8>so we can use it instead of trusted (but slow for example) <vagrantc>i think david a. wheeler's later works removed the concept of trusted and untrusted compilers, if i'm remembering correctly <Hagfish>oh, if you have two independent c++11 compilers, then they can DCC each other, sure <vagrantc>one of those D's in DDC stands for Diverse <Hagfish>if only one of them can then build a c++20, then that's fine, because you've checked the source of that compiler, presumably <melg8>i have gcc and clang - both implemented modules functionallity per 20 standard. but source code of gcc and clang doesn't rely on them by themself. if i DDC them - could i detect bad binary of clang compiler, which only subvert c++20 code? <melg8>or it will not self reproduce than? and that's it? <Hagfish>clang compiled with gcc compiled with clang should be fine, if you trust gcc not to support the subversion <Hagfish>only the original binary will have the subverting behaviour <OriansJ>melg8: DDC works as long as both Compilers are not subverted in the exact same way. <OriansJ>So if you have 1 trusted compiler then any subversion will be detected. <stikonas>and if you bootstrap that 1 compiler from stage0, that would mean all kernels/hardware would have to be subverted in the exact same way <OriansJ>So if GCC binary is subverted by Chinese Trusting Trust Attack and Clang is subverted by NSA Trusting Trust attack, you'll detect both <OriansJ>Now stage0 is spreading into EVERY Hardware platform with as many OS combinations people are willing to work on. <melg8>i think what i proposed would be detecting by self recompilation - than that c++20 subversion part will dissapear (because source doesn't have it) and sha's will differ <OriansJ>So you'll have to universally subvert *EVERYTHING* ever made and ever *WILL BE MADE* <OriansJ>Which include arbitrary hardware that Joe Soldering Iron makes in his/her garage for fun. <OriansJ>Because every piece done in stage0 can be reproduced *FOREVER* <melg8>can we than reproduce it on ethereum? <OriansJ>melg8: if someone is willing to put in the work required, yes <OriansJ>In short, every single step from hex0 to MesCC can be done by hand to verify every single byte produced. <melg8>maybe some hex part, but not till gcc xD and still that would only prove something to me myself and i) <OriansJ>After that the steps exceed human manual efforts <OriansJ>the nice thing about cc_* and M2-Planet is each function can be fully independently checked in parallel. <melg8>so... you saying i can wrap it all up with nix language - and it should give bit by bit the same - as it now runned live-bootsrap? <OriansJ>So simple create a team with as many people as there are functions in M2-Planet and just have them all produce the M1 output for each of them. Then convert the M1 into hex2 and then it is a straight process to checking every last byte <OriansJ>melg8: You can reproduce everything in stage0 on any arbitrary system you want <OriansJ>IBM 390 systems produce the same output as x86, ARM, RISC-V and SPARC <OriansJ>Windows, DOS, Linux, *BSD, VMS, OS/2, etc doesn't matter the output must always be exactly the same given the same input and flags <melg8>is there a paper explaining how that dark magic works across different architectures? <OriansJ>melg8: 8bit big endian byte encoding with hex isn't that hard to work out <OriansJ>we only work with bytes that are exactly 8bits long and in big bit endianness <OriansJ>36bit machines need to do extra work as do exotic machines with little bit endianness. <OriansJ>It is a trivial implementation problem that you can check with just 256 inputs <OriansJ>00 -> FF; everything else is just manipulation of 7bit ascii strings <OriansJ>hex2 literally only has hex characters, :labels, !8bit, @16bit, ~24bit, %32bit relative addressing and $16bit, &32bit absolute addressing <OriansJ>and # comments ; line comments to be precise <Hagfish>looks like they gave up and/or changed direction a couple of years ago, though <melg8>than from which point live-bootstrap becomes non cross-platform? <stikonas>melg8: well, stage0 binaries are also not cross-platform, it's the idea that is cross-platform <stikonas>you still have different x86 or arm binaries there <stikonas>but you can write hex*, M1, M2-Planet for all arches <stikonas>some non cross-platform compatibility then comes from driving scripts <stikonas>live-bootstrap hardcodes that in quite a few places at the moment <melg8>okay, but then how that *EVERYTHING* kicks in? so how to be globally trusted and not arm pocket of trust/ x86 pocket of trust? <stikonas>some comes from software in the bootstrap chain being non-crossplatform (e.g. need to port tcc to risc-v) <stikonas>and some comes from early build systems being non-portable <stikonas>would have to either use pregenerated configure scripts or port manually written makefiles <stikonas>you can cross-compile arm/x86 into each other <melg8>so it's always connected by DDC idea? or it will reproduce bit by bit after native vs cross compilation? <stikonas>if anything, having more different platforms/ bootstrap chains that result in the same hashes increases trust <stikonas>well, you can get bit-by bit hash match after some self-recompilation <stikonas>but e.g. native stage1 build of gcc does not have to match stage1 cross-compiled build <stikonas>(at least sourcecode after preprocessing) <melg8>so if i have fixed environment - and i have fixed GCC source code - no matter what original compiler i will use, i should after compilation of GCC with that compiler, and self recompilation of acquired compiler - same hash? <stikonas>e.g. you can't use different binutils versions, etc... <stikonas>it's more of a case "you can obtain same hashes if you put enough work" rather than "you should obtain the same hashes" <stikonas>and in any case, if native bootstrap is hard, cross-compiling might be a viable alternative <stikonas>(cross-compiled it from amd64 where rust was built using mrustc) <melg8>forgot to ask, on what stage need in kernel kicks in? <melg8>does guix path have same issue? <stikonas>well, first of all guix emulates bootstrap <stikonas>but yes, it would have all the same issues <stikonas>but early bootstrap steps are the same in guix and live-bootstrap <stikonas>it's just that guix uses guile to drive the whole process <stikonas>well, live-bootstrap in chroot mode also emulates bootstrap <stikonas>but you can run live-bootstrap directly on hardware <stikonas>but purpose of CI is to help with development <stikonas>that's not necesserily to run trusted bootsrap <stikonas>I'm not sure if anybody tried to run live-bootstrap directly on hardware yet <melg8>i mean, when something is not checked on regular basis - it tends to get out of hand <stikonas>(i.e. booting some kernel with initramfs that was prepared with ./rootfs.py <stikonas>the only cases were it was getting a bit out of hand here were actually genuine bugs (pre-generated files) <stikonas>chroot and qemu methods are both really simple <stikonas>that said, something else might get out of hand <stikonas>I think bauen1 was trying to run live-bootstrap with user-namespaces <stikonas>I guess in general when environment is very constrained and well defined, code has less bit-rot even if you don't test it <melg8>but if you don't test it - you dont detect implicit assumptions, which at the end of the day differs from ground truth <stikonas>well, those implicit assumptions are more visible in rootless bootstrap that bauen1 was trying to do <melg8>what i need to do to boot it from hardware? what is missing now? <stikonas>I guess the moral here is if you don't test different ways you don't detect assumptions, but if you test different ways you are not guaranteed to detect the <stikonas>and some trusted way to prepare boot media <OriansJ>otherwise everything else is driven by kaem-optional-seed and is built from source <OriansJ>stikonas: I think that is part of the kernel of trust (filesystem is its domain) <melg8>i think to start this to be run in reality we need some additional software - which can produce solution like plug this usb flash - and wait <OriansJ>and after checking the ether x86vm; it looks like it has everything one would need to run the stage0 steps up until TCC. <OriansJ>as Mes.c wouldn't run on that restricted set. <melg8>okay, next step would be run stage0 on genome <OriansJ>melg8: well we are also working on solving the Nexus Intruder Problem too. (Hardware compromising software, to ensure future hardware is compromised as well) <OriansJ>So there are lots of pieces to be done; we suggest you work on what you think looks like the most fun. <stikonas>in practice hardware knows very little about software it runs <melg8>i like same hashes xD of whole thing <OriansJ>FPGA work, ASIC work, making gates by hand, etc <OriansJ>stikonas: not so much these days with neural network branch prediction. <gef>> Which include arbitrary hardware that Joe Soldering Iron makes in his/her garage for fun. <gef>This is exactly why I'm inclined to explore mono-instruction machines, because they provide a thin layer of abstraction over various underlying architectures. The downside is, they are may only be good up to the instant of needing a kernel. From that moment on, things get more complicated. But the battle is not lost: if you can still checksum/verify the builds' products from your OISC trusted executor, you can still prevent the worst cases of possible <gef>i.e. bootstrap with something like SBN4 int32 architecture (even if software-simulated) and then treat loaders and even kernelized builds as mere subroutines. Trust but verify. And so on. <OriansJ>gef: I don't disagree that it certainly possible. I just wouldn't want to have to write that assembly or audit it by hand. ( I do have limits with what I am willing to do for bootstrapping you know ). So someone else would have to be convinced (or paid) to do so. <gef>sure, that's fair. Not implying it comes your way, just offering a method of we could overcome the need to cross-check architectures as we go forward. We'll see also if other ideas emerge, in the meantime! <gef>And, it's not all roses anyway, since having robust checksum functions under sbn4 is a bit hard problem - we'd need to combine several simpler such functions together to increase the level of trust. I'm still looking into this topic. <gforce_de1977>melg8: i have on my list, to provide a better floppy + build_floppy.sh script (for bare metal bootstrapping) <melg8>conceptually how from stage0_monitor.img get that floppy img? <gforce_de1977>melg8: you just print out the sourcecode, use a magnetic needle and stamp it onto a 8" floppy disc 8-) <melg8>that's not what im asking - if i have stage0_monitor.img (512 bytes, which i get from stage0_monitor.hex0) - how i can generate that 1.44 mb image? is it trivial like add some header to that stage0_monitor.img? and fill rest with zeroes? or is it containing more sofisticated binary inside? <gforce_de1977>back in the days when we used i386 PC and the DX40 was new, the term USB had no meaning and booting from other media than floppy or harddisk was black magic ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado