<stikonas>although this is only a problem if user namespaces are not enabled <doras>Or even add a small helper Python script to execute the two bootstraps. <stikonas>anyway, we can first merge this PR and then think <doras>I agree, it's definitely acceptable as it is. <stikonas>I'm approaching and of sysa, will soon know if transition works <doras>I worked hard to get it working well 😅 <stikonas>well, yeah, it's very nice not to need root for bootstrapping <stikonas>I was at some point thinking of putting it into rootless podman <doras>I like the simplicity of bwrap. <doras>But we'll have to be more careful with permissions. Not actually being root means the kernel does put additional limits on things. <doras>Is this in the suid + sudo mode, or unprivileged namespaces mode? <doras>stikonas @stikonas:libera.chat: I think bwrap disallows non-root users from gaining capabilities using as a security measure. <stikonas>yeah, that's why I was surprised when you said that most distros enable suid for it <doras>I said that most enable user namespaces. <doras>Gaining capabilities in a user namespace is less of a security concern because you are given these capabilities in a confined environment. <doras>Unlike getting them in the context of the host where you can basically do anything you want. <doras>For example, even though a user namespace can be made to "lie" about the user being root, outside the namespace it's still an unprivileged user. <doras>So if /etc/shadow is accessible only to the "real" root (i.e., the host/init root), a user namespace that maps to root will not allow a simple user to access it. <doras>User namespaces is basically either the kernel lying to user space about privileged, or allow otherwise privileged actions in a confined environment where they can't hurt anyone. <oriansj>mihi: I was looking at the assembly code of the sectorforth.asm when I made that statement and you are correct that it could by made out of the FORTH primitives provided (as the example FORTH programs clearly demonstrate) [I just assumed it was essential enough to FORTH to be a primitive] <stikonas>doras: why do we need to use find_bwrap? <stikonas>for chroot we had that shutil stuff because chroot might be in sbin which might not be in PATH ***Server sets mode: +cnt
***Server sets mode: +cnt
<oriansj>might want to add c@ and c! to sectorForth ***Server sets mode: +cnt
<oriansj>and I sorted out the rounding error and now donut.c builds and runs just fine: https://paste.debian.net/1241801/ here is the command for seeing it in all its glory: ./bin/M2-Mesoplanet --architecture amd64 -f ./donut.c -o donut && ./donut <oriansj>(probably can remove the #include "M2libc/bootstrappable.h" as that was just used to add tracing and require to get things working) ***Server sets mode: +cnt
***roptat is now known as Guest8848
<oriansj>and the generated M2-Mesoplanet code is just slow enough that we don't need a delay <muurkha>if your I/O is via key and emit, you don't ever need to store more than one byte per memory word, so you can get by without c@ and c! <muurkha>in StoneKnifeForth I did implement c! but not c@ IIRC <oriansj>muurkha: I was thinking of writing a block of bytes to directly execute later to add needed functionality for writing disk blocks <oriansj>unless you can think of a FORTH primitive for writing a block of memory to disk which would fit in the 23 remaining bytes of SectorForth <muurkha>I think 23 bytes is about enough for the BIOS call to write a block of memory to disk <muurkha>you can almost implement c@ and c! in SectorForth I think <muurkha>oh, c@'s not actually as hard as I was thinking, because 8086 has unaligned access <muurkha>: 2* dup + ; : 4* 2* 2* ; : 16* 4* 4* ; : 15 3 4* 3 + ; : 255 15 16* 15 + ; : and nand dup nand ; : c@ @ 255 and ; <muurkha>doing c! that way requires you to load in the previous word first <muurkha>I think that's : 0xff00 255 16* 16* ; variable a : c! a ! a @ 0xff00 and + a @ ! ; <oriansj>and it now takes on average more than 4 days of fuzzing to find a segfault in M2-Planet <oriansj>right now one needs to write very obviously wrong code to have a chance at segfaulting M2-Planet <doras>stikonas: I followed what we had in the chroot mode. I wasn't familiar with the reasoning behind find_chroot. I think we can rely on the PATH, yes. <doras>stikonas: regarding the removal of tmp and sysc/tmp, do you think it should happen before the bootstrap starts or after it ends? <doras>The tmpfs mounts are currently removed when the bootstrap ends, so to match the behavior it would make sense to also remove the non-tmpfs directories when the bootstrap ends. <doras>It looks like del() isn't called on bootstrap failure or Ctrl+C in the bwrap mode for some reason. I'll need to take a look at it later. <doras>If I had to guess, the chroot command probably returns 0 in such a case, while the bwrap command forwards the return code of the failing bootstrap. <stikonas[m]>doras: not sure when we should remove it, maybe fossy has any thoughts <stikonas[m]>well, tmp/sysc is actually not very useful to keep, but tmp/ is... <stikonas[m]>although eventually you want to add an option --do-not-exit, so maybe then we would keep it, otherwise delete <mihi>oriansj, I just noticed that the source code for the bootstrap seeds in bootstrap-seeds and in stage0-posix-x86 directory are slightly different (both of them) - is that intentional? :D <stikonas>mihi: no, not intentional, probably got out of sync <stikonas>mihi: for kaem the good comment should be "kaem.x86" <stikonas>but the one in bootstrap-seeds is the updated one <stikonas>mihi, can you make PRs to sync them back? <mihi>so sync the ones in stage0-posix-x86 so that they match the content in bootstrap-seeds? sure. <mihi>(or make PRs to both repos and also fix the typo on the "new" line in hex0?) <stikonas>well, basically copy kaem-minimal source from bootstrap-seeds to stage0-posix-x86 <stikonas>but hex0 source from stage0-posix-x86 to bootstrap-seeds <stikonas>(that's my impression from reading git history) <stikonas>and yes, if you fix further types, commit to both repos <mihi>also, I noticed that stage0-posix-x86 repo has no tags? I'd like to shallow clone it as part of CI, so I'd have to go the long init & fetch route instead of clone --depth=1 (which works for tags but not for commithashes) <doras>stikonas @stikonas:libera.chat: we actually already have a command argument that determines if tmp should be removed or not after the bootstrap ends. So I think the bwrap mode should act accordingly. <doras>That is, remove tmp when the bootstrap ends if the argument wasn't used. <doras>But first I'll need to find some time to look into the exit code thing. <stikonas>doras: though that said, I think we can always unmount sysc/tmp even before bootstrap begins <mihi>what is your opinion about using ^L (\f) in source code files? I know that some GNU projects use it on its own line, but mescc-tools-extra/makefile even uses it in the middle of a line... <muurkha>I think of ^L as ending a line, since whatever comes after it prints on a new page, but I don't actually remember if printers go back to the beginning of the line when they eject a page in response to ^L <mihi>the terminal does start on a new line when catting such a file, after clearing the screen. <muurkha>that is true, though it is not really desirable behavior :) <mihi>seems to depend on the terminal emulator. In PuTTY, it acts as I wrote before, linux framebuffer console will indent the new line (i.e. does not return the carriage). <muurkha>gnome-terminal puts Y indented on its own line <mihi>so PuTTY is "the odd one out". <muurkha>that is, they don't even clear the screen; they just treat it as ^J <muurkha>(but the Linux terminal driver doesn't add a ^M to ^L the way it does to ^J when stty onlcr is set) <muurkha>more surprisingly gnome-terminal (libvte) also handles ^K (\v, VT) the same way <mihi>Hmm. When I try to build sha256sum with M2-Mesoplanet, while parsing <sys/stat.h> it complains about missing <amd64/linux/sys/stat.c>? The file is not there as I deleted all other archs from M2libc, but why does it try to read a file that is #ifdef'ed out? <mihi>so, M2-Mesoplanet does not resolve #ifdefs? <stikonas>but until recently there was no #include support at all <stikonas>mihi: it does, but includes might be resolved first <mihi>ah ok. Probably fine as long as you don't do "#ifndef HAVE_BAR #include BAR #endif" in FOO and "#ifndef HAVE_FOO #include FOO #endif" in BAR :) <oriansj>mihi: the reason why M2-Mesoplanet tries to read all #includes is because the logic for filtering out the #includes would require a major rewrite in the cc_reader.c and cc_macro.c as you would have to do macro evaluation evaluation on every token and not have any look-head but have to drive reading of new tokens. <oriansj>basically a bunch of work with only the minor advantage of reading less source code files. (small performance improvement) <oriansj>(I'll review your pull requestes as soon as I get out of work) ***stikonas_ is now known as stikonas
<stikonas>bootstrap seeds looks fine too, but you'll have to merge it yourself <stikonas>doras: I think I might have found the bug in my PR that was causing change in checksums <stikonas>return statement that I added means we end up in slightly different environment <stikonas>you can't use command; rval=$? with set -e ***Server sets mode: +cnt
***Server sets mode: +cnt
***Server sets mode: +cnt
***Server sets mode: +cnt