IRC channel logs

<oriansj>I am guessing the lack of issues is a sign of good progress.

<oriansj>That or everyone is having a great friday night

<siraben>oriansj: thanks for the explanation

<fossy>i found the issue, wtf

<fossy>it is appending '~'s to everything

<fossy>why

<fossy>oh wait no

<fossy>huh

<fossy>oh my hack made that happen

<fossy>i hope that gnulib-tool works for other packages :X

<stikonas>oriansj: well, I did manage to get some work done...

<stikonas>oriansj: https://github.com/oriansj/stage0-posix/pull/30 should now be ready for merging

<oriansj>stikonas: reviewing now

<stikonas>oriansj: I'll also update bootstrap-seeds later

<stikonas>but maybe I'll try to do some experiments first if I can get something like kaem-micro with hardcoded execve commands...

<oriansj>stikonas: looks good. Merged

<oriansj>and I reached out to yt to see if he is interested in leveraging the new mescc-tools word functionality for AArch64. As we skipped this headache with AArch64 but it would make the binaries more efficient.

<stikonas>well, yes, it's a bit more pain but more universal

<oriansj>well it certainly better maps to R\

<oriansj>sorry child attack

<oriansj>well it certainly better maps to 1980s RI

<oriansj>well it certainly better maps to 1980s RISC style instruction sets

<stikonas>oriansj: so like I said I'm trying to see how big kaem-micro would be. Do you think we should use hex0-seed to build hex0 first before building kaem-minimel with hex0?

<stikonas>the other alternative would be to use hex0-seed to build kaem-minimal

<stikonas>it's 1 less command, but maybe somewhat ideal since we use hex0-seed twice

<oriansj>stikonas: well the reason for building hex0 first is to make the binary check space smaller. As kaem-minimal is a much bigger binary than hex0. So one wouldn't have to inspect the kaem-minimal binary if the hex0 binary checks out.

<oriansj>doing the hex0-seed -> hex0 ->kaem-minimal means one need only check the hex0-seed, hex0 and kaem-optional binaries

<stikonas>oriansj: small PR to remove two unnecessary lines https://github.com/oriansj/stage0-posix/pull/31/files

<stikonas>I also have a proposal for kaem-micro.S now

<stikonas>will make another PR

<stikonas> https://github.com/oriansj/stage0-posix/pull/32

<stikonas>in particular it would be nice to get a review on hex0_seed: part

<stikonas>so I think kaem-micro might be 301 byte long out: 64 byte elf header, 89 bytes of ASCII encoded strings and 148 bytes of instructions

<stikonas>well, it doesn't do much, most of the things happen in the kernel

<stikonas>hmm, maybe I should pass path to hex0-seed as command line argument

<stikonas>I think arguments can be passsed to even initramfs when kaem is used as init

<oriansj>stikonas: your kaem-micro looks promising.

<oriansj>moving kaem_minimal: after clone would reduce the number of jumps by 1

<oriansj>as parent wouldn't need to jump

<stikonas>let me see if I have the latest code in PR

<stikonas>I made some changes already

<stikonas>ok, it's not the latest

<stikonas>I reduced start_kaem part

<stikonas>ok, I pushed my latest version

<stikonas>let's see if your suggestion still applies

<stikonas>oriansj: I'm a bit confused now, but maybe because of the changes I made now

<stikonas>oriansj: did you mean this beqz s4, kaem_minimal jump can be eliminated?

<oriansj>unless I misunderstood its purpose

<stikonas>but don't we need to jump back to clone then

<stikonas>the whole thing runs twice or some parts 3 times

<oriansj>and we would be dropping the j clone for hex0 as well

<stikonas>basically I used hex0-seed to build hex0

<stikonas>then hex0 to build kaem-minimal

<stikonas>and last jump is to a bit later to execve (without clone)

<oriansj>what happens if you put an array of pointers after the program end that point to the strings? Could you simplify the logic?

<stikonas>hmm, maybe, not sure

<stikonas>well, argv is an array of pointers which I construct in the middle

<stikonas>but how would I calculate those pointers?

<stikonas>I would need to manually calculate them from base address

<oriansj>not when dealing with NASM but yes when converting to hex0

<stikonas>well, this has a slight advantaget that it's mostly a subset of kaem-minimal

<stikonas>so not much new logic

<oriansj>then you could skip the argv array generation.

<stikonas>but yeah, maybe it will still be the case...

<stikonas>hmm

<stikonas>although, hex0-seed is kind of dynamic

<stikonas>can be supplied from command line

<oriansj>I noticed that

<stikonas>so I still need to do some work

<oriansj>but one can always replace the binary in the file location dictated in our bootstrap

<oriansj>and we don't need to support additional locations either.

<stikonas>do you know if GAS supports these pointers ?

<stikonas>or do I need to go to lower level first

<oriansj>GAS should support addresses if I remember correctly.

<stikonas>well, probably it's time to read some manuals

<oriansj> https://github.com/oriansj/stage0-posix/blob/master/AArch64/GAS/cc_aarch64.S#L4675

<oriansj>or remember that AArch64 uses GAS and cc_* always needs to use such pointers to support basic types

<oriansj>and so did ARMv7l https://github.com/oriansj/stage0-posix/blob/master/armv7l/GAS/cc_x86.S#L5883

<stikonas>well, I havne't looked ata cc_* yet...

<stikonas>so didn't know that

<stikonas>it's still some time before we can reach that on riscv...

<oriansj>fortunately I am always happy to help

<stikonas>true

<oriansj>now you have a new tool to play with

<stikonas>ok, so I guess it's just .quad label

<oriansj>on 64bit architecture .word for 32bit architectures

<stikonas>well, yes...

<stikonas>hmm, so you think we should only support ../bootstrap-seeds/POSIX/riscv64/hex0-seed ?

<stikonas>override is I guess 3 instructions or so

<oriansj>stikonas: who besides live-bootstrap and stage0-posix leverages bootstrap-seeds?

<oriansj>if someone needs it later, we can always go back and add it.

<stikonas>well, nobody else uses

<oriansj>so do what makes your live easier or you find more fun. Either or both is perfectly acceptable to me.

<stikonas>well, in live-bootstrap we are using ../bootstrap-seeds/POSIX/riscv64/hex0-seed

<stikonas>altough, I think it's actually /bootstrap-seeds/POSIX/riscv64/hex0-seed there

<stikonas>but fortunately kernel treats /.. as /

<oriansj>well at the end of the day stage0-posix assumes that the binaries in bootstrap-seeds can be replaced at any time for any reason with anything that supports the minimal functionality.

<stikonas>oriansj: like this https://github.com/oriansj/stage0-posix/pull/32/files ?

<stikonas>it is simpler I guess

<stikonas>at the very least more data and fewer instructions

<stikonas>only 24 instructions now, althogh a bit more data to calculate

<stikonas>actually, we don't need to share stack, so can shorten it a bit more

IRC channel logs

2021-08-07.log