IRC channel logs
2023-11-13.log
back to list of logs
<Googulator>oriansj: like lex and yacc are also available as part of Plan 9, which is under the MIT license since 2021 <muurkha>Googulator: that's wonderful news, thanks! <Googulator>Is m4 from Heirloom used anywhere in the bootstrap? <vagrantc>ok, i think i have the patches to fix mes's clean target ... will know in 20-some minutes <Mikaku>Googulator: thanks for the fix, your PR will eventually go to upstream by rickmasters as he is upstreaming all the changes he made on Fiwix <Googulator>After bootstrap is done, you can boot back into the newly created environment by doing qemu-system-x86_64 -enable-kvm -m 8G -smp 8 -drive file=tmp/sysa/sysa.img,format=raw -nic user,ipv6=off,model=e1000 [-nographic] <Googulator>with -nographic, it gives a serial console, without it, you get Grub's graphical console (currently defaults to 1024x768) <Googulator>of course, rather than just using /tmp/sysa/sysa.img directly, it's better to make a copy of it and boot that, so you can preserve the image as bootstrapped <Googulator>also, --update-checksums is currently required since the included checksums are wrong <vagrantc>janneke: i have not confirmed by actually building, but i think the clean target for mes should remove anything not actually in the release tarball, including the *.info and pre-inst-env <vagrantc>janneke: i am not sure of GNU's standard practices around this, but at least from my workflow, the clean target should return it to essentially the same state as a freshly unpacked tarball <janneke>`clean' should not delete any files created by configure, such as pre-inst-env <Mikaku>Googulator: just for curiosity and if you don't mind, can you please share some info about that screen shot? (e.g: kernel running at the time of the screen shot, type of hardware, total build time, etc.) <janneke>...but distclean should probably also remove *.info and version.texi, as they are not present in mes' tarball <Googulator>That was still in builder-hex0, and indeed, it failed to boot further <janneke>(i guess as per GNU/autotools, they should be part of the tarball, that's probably why the confusion -- i'll fix that) <Googulator>Ended up having to use an actual HDD, because the BIOS USB stack couldn't get through loading the Linux kernel sources <Googulator>The hardware is a Core 2 Quad system from about 2006 or 2007, with 4GB of DDR2 RAM. <Googulator>As of now, the build still appears to be running - appears, because as soon as Fiwix loaded, it printed a few lines, then went to a black screen, probably because the VGA init malfunctioned. <Googulator>But based on energy usage, it's still building... well, something... in the Fiwix environment. <Mikaku>Googulator: are you using VBE frame buffer or standard VGA? <moik>Does anyone know what a "Nexus Intruder attack" is? Hard to search for online <Googulator>Kernel command line should be "fiwix root=/dev/ram0 ramdisksize=1179648 initrd=sysa.ext2 kexec_proto=linux kexec_size=262144 kexec_cmdline=\"init=/init\" <Mikaku>Googulator: Fiwix don't change the video mode, it uses what the boot loader or BIOS sets up <Googulator>Booted straight to builder-hex0 from BIOS; probably it's plain old 80x25 VGA. <Mikaku>unless you are using QEMU and explicitly appended the kernel parameter 'bga=' <janneke>vagrantc: "fix that" as in, not add them to the tarball, but remove them with `distclean' <Googulator>The hardware is actually the guts of an old gaming PC I built myself back in 2006 or 2007. All of the hardware sat untouched for over 10 years, so I can be fairly sure none of it is compromised, at least not recently enough for anything to recognize and hijack the bootstrap process <Mikaku>I have never seen a problem with standard VGA on real hardware and I'm using really old PCs here (386, 486, Pentium, etc.) <Googulator>I'm hoping display will come back once Fiwix kexecs over into Linux <Mikaku>assuming the system is alive and building <Googulator>I'll give it a couple more hours, if nothing, I consider it dead <Mikaku>why 'kexec_size=' is so big? AFAIK it should be just the size of the Linux kernel <Googulator>Because in live-bootstrap, the Linux initramfs is used to transfer pretty much everything necessary from Fiwix to Linux <Googulator>Fiwix runs without any real disk, everything is done in the initrd <Googulator>Then everything Linux will need is packaged into a Linux initramfs, which is written to ram1, together with the Linux kernel itself <Googulator>After kexec, Linux boots into the initramfs, which sets up the real disk & copies necessary data out of the initramfs onto sda1 <vagrantc>janneke: yeah, seems to be at odds with the distinction between distclean and clean ... but i can work around it in the debian packaging to get what i want :) <vagrantc>janneke: it looks to me like distclean deletes things that are actually present in the tarball and/or git. <vagrantc>janneke: then again, i may have a weird view of git, as it merges the release tarballs ... <vagrantc>the way i am managing the debian packaging, that is <Mikaku>Googulator: kexec is tricky, probably rickmasters tested its Linux boot support under QEMU only <oriansj>moik: imagine back in 1950, the idea of software designed computers is just starting to appear. You want to compromise the soviet computer infrastructure forever. So you tamper with the software used in designing hardware such that it implants a backdoor in all hardware it designs. That backdoor is then used to also compromise future software that might be used to create future hardware designs. That was the Nexus Intruder Program. <Googulator>oriansj: was anything like that actually built, or is it purely theoretical (beyond Trusting Trust in general)? <fossy>hi Googulator, i have been reading your thoughts about bare metal bootstrapping, i just haven't had a chance to get to reply in detail, but here we go <fossy>RE: "trust my current, modern system used for preparing the bare metal images" -- you are totally correct that this is a highly significant attack vector for the current bootstrapping process, although, not one that makes use of the bootstrapping process asis not worthwhile, in my opion <Googulator>Right, bootstrapping in general has other uses besides just Trusting-Trust avoidance <fossy>the issue of "more binary code written than acknowledged" you talk about, while a good start, does not protect against malicious code that happens to be the same size or smaller than the seed; i guess that this does provide a bit of defense in depth, but ultimately only makes it more *difficult* to do, not provable <fossy>"old enough that even if it's compromised, it won't recognize the bootstrap code and be able to interfere" -- this is a good point that i have put a bit of thought into, and do think that it makes sense for the vast majority of practical applications <Googulator>In theory, yes - if you can compress the seed such that the compressed seed, the backdoor and the decompression algorithm fits in the same space as the original seed, you can potentially achieve persistence though a bootstrap <Googulator>I thought a bit more about the "old enough" idea, and there's actually a balance / "sweet spot" at play <fossy>"An actual printer printing to paper would be ideal for security and trust, but it would probably be too slow." very true <Googulator>If you go too new, the risk is that the hardware is new enough to contain backdoors that target the bootstrap process (remember, a bootstrap plan might have been designed well before it's published, potentially with nefarious intent - I could be an agent working for an APT trying to sell you a flawed bootstrapping plan, for all you know) <Googulator>If you go too old, it becomes too easy to emulate the hardware using ubiquitous and easily miniaturized modern microcontrollers <Googulator>Old enough that it's unlikely an APT would've played the long game for that long <Googulator>Yet new enough that modern hardware still struggles to accurately emulate it <stikonas>by the way, matrix bridge is currently broken, I have internet outage at home, possibly for a few days <fossy>wouldn't an emulated cpu be quite distinguishable from the original hardware, thus "too old" is not so much a problem <fossy>stikonas: that is rather annoying, hopefully your internet returns soon <Googulator>Not if the system emulating it is sufficiently new/powerful <fossy>i mean, physically inspecting the hardware? <fossy>i guess theoreticlaly it could be hidden but that would be incredibly difficult to do with even the most modern hardware... <fossy>this is kinda the level where you do have to seriously consider the threat model, some of these things would be only achievable by an adversary with incredibly extensive money and time <fossy>stikonas: i have a fairly large restructuring in the pipeline, doesn't really touch the actual packages of live-bootstrap though, more how the repo is set out to make it more logical and auditable <oriansj>Googulator: unfortunately we don't know for sure. And the only way to know for sure is to bootstrap our hardware too and see if anything shows up <Googulator>If you're going back really far, like PDP-10, you can probably fully emulate its behavior using modern hardware the size of a single DIP integrated circuit used on a genuine PDP-10 <Googulator>What appears to be a transistor for ESD protection is actually the microcontroller responsible for the board's whole operation, everything else is just for show, disconnected from the circuit <Googulator>& this was done by a run of the mill tech influencer for views/clout using just YouTube ad revenue <fossy>Googulator: oh, i missed your first message, yes i am fosslinux from github <Googulator>this is why you don't just need old hardware, but rather hardware from the "sweet spot" time period <Googulator>the little microcontroller is nowhere near powerful enough to pretend to be a functional Raspberry Pi 4, but it can emulate what people before the real Pi 4's release would've expected a prototype without proper firmware to do <Googulator>imagine what an APT can do if they have to emulate not some rumored future hardware, but something like an original IBM PC <Googulator>Also, what matters for the "too new" part is not simply when the hardware was made, but also when it was last potentially tampered with (e.g. when the BIOS could've been last updated on an old motherboard) <Googulator>But it's important to remember that a BIOS update might not look like a BIOS update <Googulator>So, to be absolutely safe, beyond the secure pendrive and the special boot sector & bootstrap chain that logs everything before executing it, you also need hardware you know hasn't been tampered with recently <Googulator>"tampering" really includes executing any unaudited code here <Googulator>so ideally, one would use still sealed new-old-stock hardware for the final bootstrapping - of couse, you first test on more "expendable" hardware that's close enough in its design <Googulator>This way, the only code compiled in the last 15 years that gets to execute before its code is printed for auditing is the boot sector (typically 512 bytes) <Googulator>& we fill any unused space in it with randomness, to make int as hard to compress as possible, reducing the risk that an adversary might compress the clean boot sector + decompression code + backdoor into the same size 