IRC channel logs

<oriansj>and for extra fun x86S is going to break compatibility for our kernel bootstrap

<stikonas>oriansj: what is x86S?

<stikonas>dropping some bios stuff?

<oriansj> https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

<oriansj>basically all of the 16bit and 32bit kernel mode stuff entirely and all of the 16bit user mode stuff entirely

<stikonas>oriansj: doesn't really matter for kernel bootstsrapping

<stikonas>as those new CPUs will almost surely need UEFI

<stikonas>there isn't even compatibility mode

<oriansj>well it will break builder-hex0 entirely

<stikonas>yes, but it's already not usable on new intel systems

<stikonas>I started state0-uefi but of course it's still nowhere finished

<oriansj>hmmm.

<stikonas>well, perhaps there is still AMD CPUs that support compatibility mode right now

<stikonas>but I don't think it works well with compat mode anyway

<stikonas>Googulator mentioned that there are various issues there

<stikonas>anyway, in stage0-uefi (plus posix-runner) we can run stuff up to (and including mes)

<stikonas>tcc doesn't work for both userspace bootstrap issues and missing features in posix-runner

<stikonas>(tcc stuff creates non-continuous segments

<stikonas>that at the moment posix-runner does not know how to load

<stikonas>and of course tcc-mes on x86_64 crashes even on Linux

<stikonas>(possibly if somebody figures how to do paging, we could achieve far more in stage0-posix)

<Googulator>I doubt x86s is coming to "everyday" CPUs anytime soon

<Googulator>Probably will be Xeon-only

<Googulator>at least for a while

<stikonas>still, we need to progress stage0-uefi :)

<Googulator>obviously

<Googulator>AMD is still supporting CSM in all of their current sockets, although integrated graphics lack a 16-bit VBIOS

<Googulator>so we're good there at least until AM5 is discontinued

<Googulator>(at this point, even AM4 is continuing to receive new CPUs)

<Googulator>The big problem with x86S is that it's gonna break virtually all operating systems, even ones that are modern today

<stikonas>yeah, so you won't be able to just build old linux

<Googulator>Not just that

<Googulator>Some qemu devs tested booting several current OSes in a simulated x86S environment - nothing boots, not even Windows 11 Insider or Linux master

<stikonas>well, new ones will be fixed

<stikonas>but that could be Linux 7 or so...

<stikonas>far beyond what is buildable with GCC 4

<stikonas>which means we'll have to do another iteration of GCC before Linux

<Googulator>IMO we will need to fork GCC 4.7.4, adding features needed by newer Linux & co

<Googulator>which is already what we (plan to?) do for riscv

<stikonas>hmm, about that

<stikonas>ekaitz backported stuff to GCC 4.6

<Googulator>& then get Linus to commit to supporting the fork

<Googulator>supporting building Linux with the forked gcc, that is

<stikonas>well, that will be up to us...

<stikonas>I doubt that Linus personally will care that much about our fork

<Googulator>I mean, making sure the Linux kernel doesn't add more and more compiler checks for newer GCCs, like they do now (or if they do, add an exception for "gccboot" or whatever it will be called)

<Googulator>alternatively, it might be the kernel that needs to be forked

<oriansj>well they added the checks because their code has been broken by compiled via older compilers

<Googulator>which could be necessary if any core kernel component is rewritten in Rust

<oriansj>but yeah, it isn't a near term issue but it is definitely an issue that will take years to prepare for

<Googulator>Hard dependency of Rust is a more likely near term issue that we'll need to address

<Googulator>as I've found out with Gentoo, you pretty much can't bring up a GUI today without Rust

<Googulator>& Rust is already in the kernel, just optionally

<Googulator>(hope they don't also start depending on Zig...)

<stikonas>yeah, but kernel rust is most likely limited to non-core drivers

<stikonas>and optional

<stikonas>and later will probably just use gcc-rust

<Googulator>Right now it is, but there are plans for rewriting memory management code in Rust

<Googulator>is gcc-rust gonna be C++11 like the rest of gcc?

<Googulator>because if gcc-rust is written in Rust, then it solves nothing

<stikonas>I guess it will be C+11

<stikonas>well, eventually I think it will be harder to limit source seed to 256 MiB...

<Googulator>256MiB is relevant for trusted boot drive only, but then we aren't targeting future hardware either

<Googulator>doing trusted drive bootstrap on a CPU manufactured 5 years from now undermines trust anyway

<Googulator>by that time, an APT had plenty of time to build subversion code into the hardware with full knowledge about how we're doing bootstrapping

<Googulator>unless it's fully open hardware manufactured through verifiable means with clean provenance

<Googulator>which x86S is not gonna be

<Googulator>Looks like there has been some progress into bootstrapping OCaml: https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler/

<stikonas>Googulator: yes, it was reported here by author

<stikonas>camlboot is apparently quite slow but works

<stikonas>maybe takes 12h or so

<Googulator>& looks like ocaml's GitHub repository does go back to 4.0 and even earlier

<Googulator>What's ocaml's policy for building version N with version (N-k)?

<Googulator>Do they at least guarantee N-1?

<stikonas>probably not

<Googulator>ouch

<Googulator>hopefully not like autoconf

<stikonas>autoconf is not too bad

<stikonas>you can jump multiple versions most of the time

<stikonas>anyway, I haven't tired camlboot

<stikonas>and then follow-on bootstrap...

<Googulator>I'm referring to the incident where a commit to autoconf (or was it automake?) introduced a new language feature, whose implementation already depended on that feature

<stikonas>Googulator: probably bison

<Googulator>the actual code that was originally used to bring that feature up was never committed or even revealed, only the simplified rewrite relying on the feature

<stikonas>autoconf/automake might have something like that too to some extent but less problematic

<Googulator>bison actually sounds more probable indeed, as it directly deals with language parsing

<stikonas>because autoconf also often includes ./bootstrap script

<stikonas>that uses e.g. sed to build autoconf from autoconf.in

<stikonas>anyway, that was some old bison

<stikonas>and we do have a cleaner bison 3.4.1 bootstrap now

<Googulator>Looks like git history for ocaml does at least contain everything needed for walking the bootstrap chain, even if an N-1 policy isn't followed

<Googulator>the bad news is it's about 300 steps long, assuming nothing can be skipped

<stikonas>most likely things can be skipped...

<stikonas>I doubt that you need more than a few steps

<stikonas>the problem though is that we don't have a documentation on which ones are needed

<stikonas>maybe N-1, maybe not

<Googulator>actually, I was checkign the wrong branch (5.2 development) - for 4.14, which is what's apparently used in real life, it's actually ~110 steps "only"

<stikonas>I doubt it would be more than 10

<oriansj>Googulator: 110 steps worst case isn't bad (annoying and slow but viable); It can always be optimized and reduced. But yeah x86S and Linux having a hard Rust dependency certainly will force us to enhance Fiwix to enable more steps to run on it.

<oriansj>and 256MB trusted bootstrap is going to disappear far faster than we would want but a good many tools are bloating in features. And it is unlikely Gnode style Plan 9 on L4-SEC is likely to appear.

IRC channel logs

2024-03-13.log