IRC channel logs

2022-05-18.log

back to list of logs

<littlebobeep>.
***littlebo1eep is now known as littlebebeep
***littlebebeep is now known as littlebobeep
***ChanServ sets mode: +o oriansj
<oriansj>oh another day of productive fuzzing results wooo
<oriansj>at this rate M2-Planet will be half input validation
<oriansj>but the good news now M2-Planet will flag if you try to use a variable named any of the C keywords
<oriansj>ironically M2-Planet supports 20 of 32 of those keywords
<oriansj>and for those of you using [{(<=>)}]|&!^%;:'\" as a variable name in M2-Planet, sorry no longer supported.
<oriansj>not that it ever was a good idea to use [{(<=>)}]|&!^%;:'\" as a variable name in C code
<Hagfish>lol, yeah, i'd hope that any code auditors would flag that up if they saw it :D
<oriansj>well with a couple unicode chars it looks like just a string used by in_set that you can assign in what looked like a comment.
<oriansj>the sort of thing that would be depended upon in an attack which depended on different behavior in M2-Planet vs say GCC
<Hagfish>that is devious! yeah, all the more reason to treat non-ascii chars in source code as an attack
<stikonas[m]>Some non-ascii is fine... We do have some in the comments
<stikonas[m]>It's the ones that are non printable (control chars that are bad)
<Hagfish>what's the purpose of the non-ascii characters? i guess people's names are a valid reason (although i'd almost prefer those to be listed in a separate contributors.txt file, or something)
<f-a>my head is spinning reading how you start from assembler to arrive to gcc, with a brief escapade with guild
<f-a>*guile
<Hagfish>it's quite a trip isn't it :)
<f-a>I wonder if there are easier language to bootstrap
<f-a>I thought C would be a candidate, but apparently it is quite complex
<stikonas[m]>f-a: guile is not used to build GCC, we just build it later
<stikonas[m]>C subset is the first stuff we build in assembly, so it's good candidate
<Hagfish>i think lots of people have wondered about the most best set of languages to use, but to some extent the best path is whatever path someone chooses to put the effort into
<stikonas[m]>It's just that whole GCC need more tools, not just C compiler especially the build system
<Hagfish>yeah
<stikonas[m]>We do brief escaped to scheme (mes)
<f-a>maybe scheme syntax is itself easier?
<f-a>or forth idk
<rickmasters>oriansj: I have to apologize. In my eagerness to be helpful, I think I jumped the gun in agreeing to add immediate disk writing and large disk support
<rickmasters>oriansj: I spent some time thinking about the requirements and wrote it up for discussion here: https://github.com/ironmeld/builder-hex0/issues/3
<Hagfish>a fascinating read, thank you! i've learnt more from that "apology"/"issue" than i've learnt from some people's entire careers :)
<rickmasters>sure, it was the least I could do, for now
<Hagfish>personally i like the idea of "extra stepping stones, smaller steps" (i.e. intermediate kernels), but i'm not the one implementing/auditing this code so that's just personal preference
<Hagfish>504 MB should be enough for anyone, right?
<rickmasters>another kernel has substantial pros and cons
<oriansj>rickmasters: thank you for your honest and thought out response, it is quite helpful.
<oriansj>and I could probably get this to fit in 504MB of disk size. It just means my kernel is going to have to support downloading of tars to continue the build chain
<oriansj>but let me think deeper on this for a bit
<Hagfish>hmm, the question of when to enable (and when to assume) network access is a tough one
<rkeene>In my build system, I only enable network access during the download phase
<rkeene>( https://chiselapp.com/user/rkeene/repository/bash-drop-network-access/ )
<Hagfish>rkeene: that's such a great idea, thanks for sharing
<rkeene>I do a lot of different build systems
<bauen1>oriansj: couldn't you fit a kernel into the 504mb that allows accessing another disk with sources on it ?
<stikonas[m]>Yes,multiple disks seems a reasonable solution
<stikonas[m]>Just keep builder-hex0 as it is
<stikonas[m]>And add all other features to next kernel in C (with inline M1)
<Franciman>is GNU mes, or other bootstrapping projects interested in formal verification?
<Franciman>of the code?
<stikonas>Franciman: well, if you find it fun, why not
<janneke>Franciman: that would be amazing, but i'm afraid Mes is not ready for that yet?
<Franciman>i see, but cool
<Franciman>i was wondering how formal verification should intersect with bootstrapping needs
<theruran>Franciman: what about verifying the assembly? such as using Vale https://github.com/project-everest/vale
<Franciman>interesting!
<theruran>or ACL2 has an x86ISA book https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/X86ISA____INTRODUCTION?path=3760/2963/10720
<Franciman>thanks
<Hagfish>hmm, a self-propagating backdoor would have to include a copy of itself in any compiler that it compiled
<Hagfish>that seems like something an invariant you could rule out through static analysis
<Hagfish>but i guess the problem is "what system do you trust to run this analysis program on (and why do you trust that program to do what it says)?"