IRC channel logs
2024-01-17.log
back to list of logs
<lrvick>using this as a drop-in replacement for alpine as the bootstrap container for the distro <muurkha>lrvick: congratulations! that's fantastic! <muurkha>hopefully that will make it enormously easier for people to reproduce reproducibility <lrvick>Just now realizing after all this this only gets me to 32 bit gcc13, which cannot build musl for x86_64 to then build gcc as x86_64 <lrvick>it is actually not obvious to me the best order of operations to bootstrap myself up to a x86_64 toolchain from here. <lrvick>Okay seems like the play is, let bootstrap x86 gcc13 build x86_64 gcc, then use that to build x86_64 musl, then from there build out all my usual 64 bit toolchain <lrvick>If anyone has successfully cross compiled a x86_64-linux-musl tooolchain from a i386-linux-musl base like live-bootstrap, I would love the reference. Trying to use "musl-cross-make" as a guide but binutils explodes with what seem to be 64bit related issues: https://dpaste.org/AXAiB <Googulator>Mikaku: does Fiwix itself ever run 16-bit code or make BIOS calls, especially early in its startup? <matrix_bridge><Andrius Štikonas> lrvick: what order are you building packages? <matrix_bridge><Andrius Štikonas> Some runes from Linus from scratch might be useful <lrvick>I was trying to build binutils first as most cross compiler guides seem to do that <matrix_bridge><Andrius Štikonas> Our binutils should already support 64 bit binaries <matrix_bridge><Andrius Štikonas> I think we pass required configure option <lrvick>in that case I guess I need to skip to gcc <matrix_bridge><Andrius Štikonas> Then build native GCC and binutils (not sure about order here) <lrvick>weirdly I was able to build 64 bit busybox, but other binaries exploded. <lrvick>I assume busybox ships with magic <matrix_bridge><Andrius Štikonas> We should try to get native 64 bit bootstrap working too... <lrvick>Trying gcc now. fingers crossed (pun intended) <matrix_bridge><Andrius Štikonas> But userspace is probably not too far from working <Googulator>Can gcc 4.0.4 running in Fiwix build a 64-bit Linux kernel? <Googulator>As I imagine that would be the ideal next step: changing the Linux kernel build from 32-bit to 64-bit with support for a 32-bit userspace <Googulator>& then as we boot into Linux. we can transition to building 64-bit binaries <matrix_bridge><Andrius Štikonas> We probably still want to support 32 bit mode <Googulator>Although a case could be made for always bootstrapping with the system clock set to a predefined value, say the Unix epoch or Y2K <Googulator>of course, that complicates HTTPS, which is time-dependent :( <Googulator>It could be worked around using a forwarder that locally hosts binaries over HTTP (or HTTPS with certificates defined as valid for the bootstrap epoch), which would also reduce exposure of the bootstrap system to potentially malicious HTTP(S) hosts <Googulator>as right now, I'm rather concerned with the fact that we're allowing an unpatched 4.9.10 kernel to receive TCP streams from untrusted or at best semi-trusted Web hosts <Googulator>Checksums mean we can safely tolerate plain HTTP - but none of that protects against attacks involving malformed packets / TCP streams that try to execute code in the kernel space <Googulator>Just a short while ago, we had to change our source for OpenSSL from artfiles.org to mirror.math.princeton.edu because the former started redirecting to HTTPS - but do we trust either of those sites to _only_ serve us the openssl sources over HTTP, without doing any shenanigans in the low level packet stream? <Googulator>More importantly, do we trust these sites *not to get hacked* to then do shenanigans? Compromise mirror.math.princeton.edu, patch the HTTP server, and you compromise the bootstrap process. <Googulator>Checksums are of no help, because once you get kernel mode ACE, you can install your payload, and then serve the real openssl sources, which userspace gladly accepts because it does have the correct checksum - the exploit happened earlier. <Googulator>(of course, all of this is predicated with Linux 4.9.10 actually having a kernel mode ACE vulnerability exploitable via TCP) <lrvick>As a qubes user I never want my host kernel I must trust to touch the network for the reasons you outlined. Though building/shipping qemu to use only as a download proxy would be a lot... but also reasonably safe. I assume there are a long list of blockers there. <Mikaku>Googulator: nice catch on PR #68 <Googulator>of course, it doesn't explain pder's issues, since that should only come into play when going from Fiwix to Linux <Mikaku>rickmasters and me missed that bug <lrvick>if no one has hit this yet, I can try the workarounds and see what happens <pder>The issue Ive been having during Fiwix boot is still mysterious. I tried enabling CONFIG_QEMU_DEBUGCON in include/fiwix/config.h and added -debugcon /dev/stdout to qemu options and Fiwix boots and carries on <pder>rickmasters: I appreciate the offer and I might take you up on that after exhausting a few more things <Googulator>What if you add CONFIG_QEMU_DEBUGCON, but not actually enable the debug console in qemu? <pder>Googulator: trying that now <pder>Googulator: boots into Fiwix and continues with CONFIG_QEMU_DEBUGCON but no additional parameters to qemu <lrvick>The stdc-predef.h error was a red herring. True error was "configure: error: cannot compute suffix of object files: cannot compile" when configuring libgcc: https://dpaste.org/h3dOK/raw <lrvick>Maybe I need to force a system include path or something.