IRC channel logs

<muurkha>though it would be better with longer variable names in some cases

<rickmasters>I just changed wstrcpy to this, which seems to fix it:

<rickmasters>int i = 0;

<rickmasters>do {

<rickmasters> destination[i]=source[i];

<rickmasters>} while (source[i++] != 0);

<rickmasters>After that fix, flex-2.5.11 and then musl-1.1.24 finishes on fiwix.

<rickmasters>Then it fails on "build tcc-0.9.27 tcc-musl-pass1.sh"

<rickmasters>It builds tcc-musl, but has a memory fault trying to build tcc-musl with tcc-musl.

<rickmasters>I'll start digging into that.

<stikonas>rickmasters: if that works with linux, can you make a pull request?

<rickmasters>stikonas: sure. I just edited the patch rather than reconstruct it. Is that ok?

<stikonas>yes, that's fine as long as it applies

<stikonas>maybe musl is doing something that crashes fiwix?

<rickmasters>yeah, i kept the number of changed lines the same for wstrcpy

<stikonas>I think emacs even fixes changed line numbers for you

<rickmasters>to clarify, fiwix doesn't crash - the process triggers a general protection fault and is terminated

<rickmasters>muurkha: it *appears* that fiwix will zero any mapped page not backed by an inode: https://github.com/mikaku/Fiwix/blob/ad7da45d44aa0cea54718df6deb32aac3c36f3c3/mm/mmap.c#L432

<rickmasters>So, digging further might take some time. But can you think of problems other than uninitialized stack variables that might occur if it doesn't zero the stack?

<oriansj>I can think of a couple optimizations that might assume the default stack is zero but none that should absolutely be needed.

<oriansj>muurkha: if you notice knight zeros memory on stack pop

<oriansj>and the compiler should be putting zero on the stack prior to use anyway (regardless of what the kernel does)

<muurkha>oriansj: it's not clear to me whether the Fiwix kernel is intended to provide security boundaries between processes (i.e., support some processes having more privileges than others)

<muurkha>but if it is, it wouldn't be okay for it to rely on the compiler for those security boundaries

<muurkha>the fact that it supports the Linux system call interface implies that you can use a malicious compiler

<muurkha>rickmasters: I explained the problem in the post I linked above on the orange website

<muurkha>(the problem other than uninitialized stack variables that might occur if it doesn't zero the stack)

<muurkha>with arrays in the stack frame that are set up by calling functions (such as wstrcpy!), having the compiler pre-zero them would be a performance loss, and potentially a significant one in some applications

<muurkha>though not a relevant one here

<stikonas>and at the moment M2-Planet does not pre-zero arrays on the stack

<muurkha>for M2-Planet, the performance loss should not be an issue

<rickmasters>muurkha: so, the leakage of confidential information? Yes, it would be a problem for fiwix, but not something that would stop me in my tracks in this bootstrapping effort.

<rickmasters>A malloc issue would be a heap problem of course rather than stack but its the same issue in the sense that the kernel needs to zero that too and probably manages it in a similar way

<muurkha>no, it's probably not a problem relevant to bootstrapping, but it's a problem a kernel needs to solve to provide security boundaries between processes

<muurkha>agreed about malloc

<stikonas>indeed, leakage of confidential information is not a big deal in bootstrapping

<stikonas>we have full control of what code we run there

<stikonas>and checking hashes of all programs actually would help to spot if any uninitialized data somehow propagated into executables

<muurkha>yeah, it could cause a determinism problem

IRC channel logs

2022-11-23.log