IRC channel logs

<hl>Hello there

<Googulator>deesix, lanodan: dismissing x86 seems excessive, given that AFAIK Socket AM5 CPUs can boot unsigned firmware from a USB mass storage drive (also, we have good RISC-V and ARM64 boards with the same capability, which should be much easier to target with modern tooling than POWER)

<Googulator>But overall, it's very close to the "trusted flash bootstrap" idea I proposed for live-bootstrap a while ago - except, I treated new-old-stock, still sealed x86 parts older than 15 years as trustworthy, because it's exceedingly unlikely even for an APT to anticipate bootstrapping techniques 15 years into the future

<lanodan>By sealed do you mean like "only had trusted data in" similar to like an air-gapped setup? Because I doubt there's 15+ years old part that have never been used.

<lanodan>At least I have some ARM boards that haven't been powered on in 10+ years, but well 10+ years arm doesn't have any form of generic boot so pretty much a non-starter for bootstrapping.

<lanodan>I think VM approach across different machines could be more interesting as a way of reproducing things out, specially as that allows hosts of different architectures and eras more easily.

<Googulator>No, I mean actual new-old-stock parts still in their original packaging. They are rare, but they do exist.

<lanodan>Yeah not impossible but still kind of implausible to me for such a long time, like it would typically end up passing hands after such a long time, so I guess a long search

<aggi>lanodan: ARM devices relying on uboot-loader are problematic

<aggi>because, to compile uboot that needs swig utility nowadays, which is c++

<aggi>so, for some tiny boot-loader with a few hundred lines of code it is a hundred million lines of code in the toolchain pulled in to compile this

<aggi>that is similar to x86_32 with af few lines of 16 bit real-mode boot-code written in GNU gas syntax - which pulls in dozens of millions of lines of code for binutils

<aggi>earlier linux-2.2 kernels had implemented their bootcode with Intel syntax instead, so there is a chance to compile/assemble those with bin86/as86 utility

<aggi>i've had no time yet to rewrite/port linux-2.4 bootcode for as86/bin86, but it's feasible

<aggi>there was reasons NASA dumpster dived for 8086 era parts: http://tinyfront.mooo.com/docs.html#fn:10

<aggi> http://tinyfront.mooo.com/docs.html#fn:11

<aggi>nowadays, for some kernel/userspace to retain C-toolchain portability i dumpster dived into RedHat and Gentoo archives backtracking software over 20years of development for some missing pieces

<aggi>recently, that's been some TeX "only"

<matrix_bridge><Andrius Štikonas> if somebody is capable of doing binary level propagating attack, surely they can manufacture 15 year old looking packaging

<aggi>other than the fact with the gigantic size of toolchains of a hundred million lines of code it's not feasible to review all of this

<aleksih>stikonas: That's great! I'm trying out building tinycc, and it seems nyacc preprocessor is not working right. I see the dev branch for 3.03 seems to have a test case for the exact issue re: ELFW macros

<aggi>teTeX-3 bootstrapping/compile with tinycc passed: autoreconf, compile, link, install... done.

<aggi>i've deactivated the c++/xpdf codepath for this, don't know what that was good for, and there is some other c-codepaths related to pdf output still

<aggi>so now, there's TeX and pdf support with a bootstrappable tinycc/linux system available

IRC channel logs

2026-02-13.log